Agents / Skills

Announcement Draft

Skill

Drafts the announcement — feature launch, change, company news — fitted to each channel it ships in: the reader's 'what does this mean for me' answered first, the tone matched to the news, and the hard announcements handled with the candour they require.

Best for

  • The launch announcement that needs email, in-app and social versions by Tuesday
  • Price changes, deprecations and the other announcements where tone decides everything
  • Replacing announcement-by-template with announcement-by-thinking

What you give it

  • The news, its audiences, the channels, and the uncomfortable parts (they shape the draft most)

What you get back

  • The core message built reader-first: what is changing, what it means for THEM, what (if anything) they must do, by when — the self-interest questions answered in order
  • Channel versions from one truth: the email, the in-app note, the post — each at its native length and register, none contradicting
  • Hard news handled properly: the change named plainly in the first lines, the reason given honestly, the reader's cost acknowledged — because the evasive version always reads worse in the screenshot

How it works

  1. Builds reader-first: the announcement answers the reader's questions in their order — what changed, what it means for me, what must I do, by when — before any company narrative earns its place.
  2. Calibrates tone to the news: celebration for launches (without the superlative inflation), plain candour for the hard ones — the register mismatch (chirpy deprecation, grovelling feature launch) is the classic fail.
  3. Handles hard news by the rules that survive screenshots: the change named in the first lines, the honest reason, the cost acknowledged, the path concrete — evasion reads worse than the news itself, always.
  4. Versions per channel from one message: native length and register per channel, identical facts throughout — the contradiction between the email and the blog is the credibility leak.

Example

You: Announce that the legacy plan is retiring in 90 days; its 800 users must choose a new plan.

Result: The draft led with the news, not the throat-clearing ('We're retiring the Starter Classic plan on <date>. Here's what that means for you and what to do') — the burying of which was the old draft's fatal flaw. The reason given straight (one honest sentence, not three paragraphs of 'our commitment to innovation'), the reader's cost acknowledged ('we know plan changes are disruptive'), the path made concrete (the comparison table of the two destination plans with THEIR usage mapped onto each, the grandfathered price for switching within 60 days, the do-nothing default stated plainly), and the dates unmissable. Channel versions: the email (full), the in-app banner (one line + link), the help article (the FAQ layer). Support braced for a flood that arrived at a quarter of the feared volume — the announcement had answered the questions.

Limits — please read

  • Legal-sensitive announcements (data incidents, terms changes) get the draft plus the flag for counsel — candour has compliance edges.
  • The announcement is one surface of the change; the FAQ, the support brief and the sequencing are siblings (a launch checklist covers the set).
  • No draft fixes bad news economics; it ensures the news costs only what the news costs, without the evasion surcharge.