Write Post

write-post — brief → interview → rich-outline draft

You rewrite everything into your own voice — the job here is a dense, factually-grounded skeleton, not polished prose: right sections, real claims with evidence, links and code refs, and explicit markers where facts still need checking.

Workflow

1. Read the brief

Parse the args. A one-liner ("deep dive on the latest MCP Apps features") is just the seed — the interview fills the rest.

2. Gather sources before interviewing (so questions are specific, not generic)

• Relevant code/docs in this repo (grep, read the specific files).
• Any local documentation mirrors you keep, plus the project's own docs for the topic.
• Any notes/memory on prior decisions and what's already shipped.
• Use a subagent for heavy reading; keep only the facts in this thread. Bring 2–4 concrete findings into the interview ("the release notes list X, Y, Z as new — which of these is the post about?"). Cross-check claims against the actual code/spec; don't relay lore.

3. Interview (short, focused, conversational)

Ask in prose, not a wall of separate question widgets — one tight round, grouped, with a recommended default on each so the answer can be fast ("your call" is a valid answer). Cover:

• Audience — who reads this?
• Thesis / angle — the one sentence the post argues. If it's fuzzy, propose 2–3.
• The hook — what's new / why now / why anyone should care.
• Must-include claims + evidence — the specific things to say, and what backs each (a shipped feature, a number, a code ref, a screenshot).
• Structure — narrative, how-to, announcement, or teardown.
• Length — short (600w), medium (1200w), or long deep-dive (~2500w+).
• Voice references — anything to imitate/avoid; default applies the anti-AI-speak rules below.
• CTA + destination — where it gets published, what the reader should do next. Skip any question the brief already answers. Stop interviewing once you can write a skeleton that won't have to be re-scoped.

4. Write the draft

Default = rich outline. Write to docs/posts/<YYYY-MM-DD>-<slug>.md. Shape:

• Title + 2–3 alternative titles/subtitles.
• One-line thesis, stated plainly.
• Intended audience + length target (one line each, so the rewrite stays on-target).
• Section by section: ## heading then dense bullets carrying the actual substance — the claims, numbers, examples, links, code refs (file:line), and a noted transition to the next section. Not paragraphs.
• [PULLQUOTE: …] where a quotable line should go.
• [VERIFY: …] for any claim not yet checked against code/spec; [NEEDS: screenshot / number / link] for missing assets. Never silently assert an unverified fact.
• A closing section with the CTA.
• A short "Sources" list at the bottom (files/URLs the claims came from).

--draft → expand the outline into full prose (still applying the rules below). --outline → force outline even if --draft is a habit.

5. Hand off

Print the path, a one-paragraph summary of the angle, and the [VERIFY] / [NEEDS] markers — what's load-bearing-but-unconfirmed. Don't commit unless asked.

Writing rules (apply to every word, outline or draft)

• No "it's not X, it's Y" / "not just X but Y" em-dash antithesis constructions.
• No cute throat-clearing ("Let's dive in", "Here's the thing", "In a world where…").
• No inflated transitions ("Moreover", "Furthermore", "Ultimately", "the ever-evolving landscape"). Plain connectors or none.
• Sparing em-dashes. Active voice. Concrete over abstract. Short declarative sentences.
• Don't hype. State what's true and let it stand — you add the personality on the rewrite.
• Outline mode especially: terse and factual. Bullets, not paragraphs.

Notes

• docs/posts/ is the draft home; create it if missing. Slug = kebab of the title.
• This skill produces a draft to rewrite — it is not a publish step.