Each night, review publicly released product changes and select only those users need to know. Verify each against the product, docs, or release notes. Use the Jellypod MCP to turn the approved changes into a three-to-five-minute podcast explaining what changed, why it matters, and how to try it. Check the script and audio for accuracy, clarity, and pronunciation. If nothing meaningful shipped, make no episode. Ask before publishing. Finish with the draft episode, sources, and review result.
claude-code · codex
Use this when
Use this when a product ships frequently enough that users would benefit from a short recurring audio explanation of what changed and how to use it.
How it runs
Collect the previous day's public product changes, documentation, and release notes.
Select the changes most meaningful to users and verify what actually shipped.
Use Jellypod to draft a three-to-five-minute episode covering the benefit and how to try each selected change.
Review the script and audio against the sources, regenerate weak passages, and request approval before publishing.
Done when
✓ The episode accurately covers every meaningful public update. Finish with a review-ready three-to-five-minute episode, or a confirmed no-episode result when nothing meaningful shipped.
Why it works
A fixed release window keeps coverage current, while editorial selection and source verification prevent the episode from becoming an automated reading of commit titles.
Implementation note
Use only publicly released information. Do not expose private repository context, customer data, security-sensitive details, or unreleased work in the generated episode.
Find a repeatable weekly post format for [approved account, audience, and topic] through a six-week experiment. If the account, audience, or topic is missing, ask for it before drafting. Obtain approval before publishing anything externally. Each week, draft one short post about a real problem [person, product, or company] solves. Record substantive replies, saves, and questions after the same measurement window. Treat likes as secondary evidence. Keep the audience, topic area, cadence, and measurement window comparable. Change only one meaningful element each week, such as the opening, format, example, or call to action, based on the strongest signal from the previous post. Stop when one format materially outperforms the alternatives, the six-week experiment ends without a winner, approval is withheld, required metrics are unavailable, or the budget is exhausted. Never fabricate engagement data. Finish with every post, its measurements, the variables tested, the winning format or no-winner result, and the next recommendation.
Improve [landing page or purchase page] using objections from recent buyers. Before contacting anyone, identify the approved buyer group, outreach channel, privacy rules, and message. Obtain explicit approval for the outreach. Interview buyers in batches of five, up to fifteen people total. Ask each person one question: What almost stopped you from buying? Record their exact words while protecting their identity and honoring any consent or communication requirements. After each batch, group repeated concerns and draft a proposed copy change for the point on the page where each concern is most likely to arise. Do not publish the copy without approval. Use the next batch to check whether the same concern still appears. Stop when the concern no longer repeats, fifteen interviews are complete, the outreach budget ends, or access is blocked. Finish with anonymized quotes, recurring concerns, proposed copy, evidence by batch, and the recommended page change.