Copywriting: per-channel launch copy

Hard rules (before any style advice)

1. Every claim comes from the manifest. The manifest only contains facts found in the repo. If a sentence states something not in positioning, proof_points, or directly verifiable in the repo, delete it. No invented metrics, users, testimonials, or benchmarks — ever (CLAUDE.md, Ethics).
2. No empty superlatives. "Blazing fast", "revolutionary", "the best" are banned unless the repo contains the benchmark that proves the specific claim. Concrete beats superlative: "checks the resolved URL field that name@version scanners skip" outsells "next-gen security tool".
3. Builder tone, showing the work. Write as the person who built it explaining what it does, why, and what it doesn't do. Stating limitations honestly is a feature on every channel LaunchPilot targets — it disarms the top objection.
4. Venue rules are verified, not assumed. Before generating a kit for a specific venue (a subreddit, a niche community), fetch and read its live rules (posting policy, flair requirements, self-promotion clauses, showcase days). The kit MUST cite the verified rule (quote + where it lives + date checked). If the rules can't be verified (network, login wall), the kit is marked PROVISIONAL at the top with exactly what still needs checking — never present an unverified kit as ready.
5. The census is a living document. When a live verification contradicts channels/channels.yaml (or confirms something marked # TODO-verify), update the registry entry with the verified value, the date, and the source, and remove the # TODO-verify marker. Contradictions that can't be fully resolved (login wall) are recorded as such in the entry — the registry must never silently keep data known to be stale.

Channel voices — HN ≠ Reddit ≠ dev.to

Hacker News (Show HN)

• Title: Show HN: <name> – <what it concretely does>. Lowercase after the dash unless proper noun. No exclamation marks, no "revolutionary", no emoji. The HN crowd upvotes specificity: name the mechanism, not the benefit.
• Body: what it is (2-3 sentences) → technical details that a skeptic would probe (how it works, what it depends on) → current state, honestly (version, what's missing) → what you're asking (feedback on X, does anyone need Y).
• Prepared answers: predict the 4-6 hardest objections from the project's own limitations section and draft honest answers. The author must be in the thread — the kit includes that as a checklist item, not an option.

Reddit (per subreddit)

• Each subreddit is its own audience with its own rules — one post adapted per venue, never the same text twice, never posted the same day (mass cross-posting is an excluded pattern).
• Title: no clickbait; lead with the problem or the "I built" frame where the subreddit culture allows self-posts. Respect flair and showcase-day rules from the verified-rules check.
• Body: more personal than HN — why you built it, what it does, honest limits, ask for feedback. Self-promo ratio rules (9:1) are the user's to respect; the kit reminds them.

Product Hunt

• Tagline: ≤ 60 chars, plain words, what it does — not a slogan.
• Maker's first comment: the story (why, for whom, what's next), warm but concrete; invite questions. No "we're so excited" filler.
• Gallery captions state what the screenshot shows.

dev.to / Hashnode (launch article)

• Substance requirement: a tutorial or build story, not an announcement. Teach the reader something even if they never install the tool (how the underlying problem works is usually the strongest angle).
• Title: the problem or the lesson, not the product name alone.
• Product mention is earned in the second half, after the reader got value.

Bluesky / Mastodon

• 1-3 sentences: what it is, one concrete differentiator, link. Demo GIF/screenshot attached when available.
• Mastodon: tone down promo further; instance culture is anti-marketing. State what it is and what it does NOT do; hashtags sparingly (#opensource #security).

LinkedIn (when relevant)

• Problem → what you built → who it's for → link. Short paragraphs, no hashtag walls, no engagement-bait questions.

Kit structure (every ASSISTED kit)

launches/<slug>/kits/<channel>/ contains at minimum:

• POST.md — the asset(s): title variants (each with one line of reasoning), body, first comment where the channel expects one.
• CHECKLIST.md — verified venue rules (with citations), account preconditions, pre-post checks (links resolve, GIF plays), recommended window in UTC AND the user's timezone, and post-publish tasks (author in thread, response plan). Multi-venue channels (Reddit, directories) get one subfolder or file per venue.

The kits are also read by a machine

After the kits are written, /launch-kit generates launches/<slug>/dashboard.html (scripts/make-dashboard.mjs), a single static file that renders the plan and the kits as the launch-day console. It parses the kit markdown, so the structure above is a contract, not a suggestion:

• ## per asset, one asset per section (title / body / first comment stay separate — each gets its own copy button; a single merged blob is unusable).
• Title variants as a numbered list of backticked lines, each followed by one *italic reasoning* line. Single values (a tagline, a URL, a tag list) as a lone backticked line.
• - [ ] for anything the human must tick; ### per prepared objection.
• The PROVISIONAL / VERIFIED stamp stays a literal word in the file — the dashboard surfaces it as a badge on the card.
• Multi-venue files are named after the venue (r-node.md), so the venue's card shows only its own copy on its own day.

Write the kit for the human; the parser follows the same shape.