Release Announcement
Write a public-facing release announcement that turns a shipped version into a compelling story for users — a blog-post / email-style piece that leads with the headline value, shows the marquee features with concrete before/after benefits, links to the full release notes and upgrade path, and ends with a clear call to action. A planner picks the 2-4 things actually worth announcing and the audience/channel, a copywriter writes the benefit-led announcement in the brand voice, and a reviewer checks it is accurate, on-message, and that every claim traces to a real shipped change. Use this for product launch posts, 'what's new' announcements, version launch emails, and changelog-to-marketing translations.
Steps
Entry step: scope. Each step names the specialist role it wants; the full working prompt is expandable.
- Scope the announcementplannerentry
pick the marquee items, audience, and channel
Show working prompt
1. Review the release contents (changelog/release notes) and pick the 2-4 changes genuinely worth announcing — the ones users will care about, not an exhaustive list. 2. Identify the audience and channel (blog, email, in-app) and the single headline benefit of the release. 3. For each marquee item, capture the concrete user benefit and a before/after framing ('used to take X, now Y'). 4. Decide the call to action (upgrade, try it, read the docs) and the link to the full release notes. 5. Set the tone to the brand voice and a target length appropriate to the channel. 6. Good looks like: a short brief listing the headline, the 2-4 marquee items each with a user benefit, the audience/channel, the CTA, and the release-notes link. Write this as an acceptance-criteria checklist ('leads with the headline benefit', 'each marquee item states a user benefit not a feature spec', 'every claim traces to a real shipped change', 'has a clear CTA and a link to full notes', 'matches the brand voice and channel length') plus the brief to the notes file via write_task_note AND to notes/scope.md. - Write the announcementcopywriter
benefit-led launch story in the brand voice
Show working prompt
1. Open notes/scope.md and write the announcement leading with the headline benefit in the title and opening line — hook first, not 'We are pleased to announce version X'. 2. Give each marquee item its own short section with a benefit-led subhead and the before/after framing, written for users not engineers. 3. Keep the voice consistent with the brand and the length appropriate to the channel; scannable subheads and short paragraphs. 4. Include the call to action prominently and link out to the full release notes / upgrade guide. 5. Do not over-claim or mention anything not actually shipped. 6. Good looks like: a tight, benefit-led announcement a non-technical reader enjoys, every marquee item from scope.md covered with its benefit, a clear CTA, and a notes link. Write the announcement to announcement.md.
- Review for accuracy and messagereviewer
verify claims trace to shipped changes and tone is on-brand
Show working prompt
1. Open announcement.md and cross-check every feature/benefit claim against notes/scope.md and the actual release — flag anything over-claimed, vague, or not actually shipped. 2. Confirm it leads with the headline benefit and that each marquee item is framed as a user benefit, not a raw feature spec. 3. Verify the CTA is present and the link to full release notes resolves. 4. Check the voice is on-brand and the length fits the channel; flag engineer-speak that leaked into a user-facing piece. 5. Write a PASS/FAIL per acceptance criterion with specifics; any failure routes back to the write phase. Write findings to notes/review.md.
- Evaluatereviewer
Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.
Show working prompt
Open announcement.md and verify it against notes/scope.md, PASS/FAIL each criterion. Confirm: (a) the title and opening lead with the headline benefit; (b) each marquee item from scope.md has a benefit-led section, not a raw feature spec; (c) every claim traces to a real shipped change with no over-claiming; (d) a clear CTA and a link to the full release notes are present; (e) the voice matches the brand and the length fits the channel. Any FAIL routes back to the write phase. Then route — this is the whole point of the loop: - **Every criterion PASSES →** call `advance_task_step({ ref, stepId: "evaluate", next: "finish" })`. - **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: "evaluate", next: "write" })` to loop back. The builder fixes exactly those gaps. Never route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in. - Finishdeveloper
All acceptance criteria met. Stamp a short summary and report DONE.
Show working prompt
Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.
Triggers
Phrases that suggest this craftbook to a crew.
- announce the release
- what's new post
- launch announcement
- blog post for the new version
- release marketing copy
Source
View this craftbook on GitHub · MIT license