/loopcontenthigh riskintermediatesafety C · 65Forward Futurepre-dates current gate · under review

Turn product changes into a podcast

Each cycle, turn meaningful public product changes into a short, source-grounded podcast episode.

prompt
→ Claude
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

  1. Collect the previous day's public product changes, documentation, and release notes.
  2. Select the changes most meaningful to users and verify what actually shipped.
  3. Use Jellypod to draft a three-to-five-minute episode covering the benefit and how to try each selected change.
  4. 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.

Source: Forward Future ↗

More content loops

Interview five buyers, fix the copy

/loopForward Futurenew

Interview recent buyers in batches, track recurring objections, and propose evidence-backed landing-page copy.

prompt
→ Claude
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.
contentlow risk

Fact-check before you publish

/goalForward Futurenew

Inventory checkable claims, verify them against primary sources, repair high-risk mismatches, and log what stays unresolved.

prompt
→ Claude
Before publishing [draft], inventory every factual, statistical, quoted, or attributed claim a reader could verify. Find the best current primary source for each and label it supported, outdated, misattributed, unsupported, or unverifiable. Fix the riskiest mismatch, then recheck that claim and anything depending on it. Repeat until no high-risk unsupported claim remains or five rounds are exhausted. Never invent a source, cite evidence that does not support the claim, or alter a quotation. Ask before changing a named person’s quote or a legal, medical, or financial statement. Stop without changes if there are no checkable claims; stop as blocked when adequate evidence is unavailable. Finish with the claim-to-source table, corrections made, unresolved claims, and decisions requiring an editor.
contentlow risk

Draft a LaTeX preprint, claim by claim

/loopForward Futurenew

Build a seven-section LaTeX preprint with native figures, traceable claims, repeated compilation, and stated weaknesses.

prompt
→ Claude
Create a complete LaTeX preprint about [topic] using [supplied sources, assumptions, and data]. If the topic or required source material is missing, request it and stop. Do not invent claims, citations, or data. Use explicit placeholders for missing information. Include exactly these sections in order: Abstract, Introduction, Methods, Results, Discussion, Conclusion, and References. Build every figure and table with native LaTeX tools such as TikZ, pgfplots, and booktabs. Do not use \includegraphics, \svg, or external image files. Every substantive claim must trace to a numbered equation, citation, supplied datum, or labeled assumption. Compile using the project's documented command or latexmk when no command is specified. Inspect compilation errors, warnings, typography, cross-references, and figure placement. Fix the most serious issue and compile again for at most five rounds. Stop when compilation has zero errors, all seven sections are present, every figure and table is referenced before it appears, and no banned command remains. Otherwise stop as blocked or exhausted. Finish with the .tex file, compilation command and log, structural checks, three substantive weaknesses, three typography issues, and unresolved placeholders.
contentlow risk