Launch README

The README's first screen (about one phone screen — roughly the first 25 rendered lines) is the landing page for every launch post. This skill rewrites that screen and leaves the rest of the README alone unless asked.

Before you edit

• Read .megaphone/decisions.md if it exists (languages the user can reply in, target channels) and record new answers or, with no human available, assumptions there.
• Read .megaphone/brief.md. If it doesn't exist, do a quick pass of ../launch-positioning/SKILL.md first — a README can't be sharper than its pitch.
• Read the whole current README and keep everything that's accurate. You're reorganising and tightening, not deleting the author's documentation.
• Commands must be real. Never invent flags, package names or URLs. You may compose a command from verified parts (documented flags, files that exist on the default branch, e.g. curl -s <raw-url-of-repo-sample> | tool -); mark it # verify and add "run the quick start on a clean machine" to the user's to-do list. If the project isn't published to a registry, use the real install path (clone + run).

The first screen, in order

1. Name + logo (optional) as the H1. Keep the logo small; it mustn't push the tagline below the fold. A logo is not the visual.
2. Tagline — the brief's one-liner, as plain text directly under the title.
3. Badges — at most one row, only ones that carry information (version, license, CI, downloads). Remove broken or stale badges.
4. Links row — Demo · Docs · 中文 / English · Discord, whichever exist.
5. Visual — a screenshot, GIF or short video of the aha moment. If none exists, leave a clearly marked placeholder and put "record a demo" on the to-do list with exactly what to capture (the aha-moment steps, under 15 seconds, no dead time).
   • Recording: VHS or asciinema for text-only terminal output; a screen recorder + gifski if the tool draws images (Kitty, iTerm2, Sixel) or has a GUI.
   • Host it where the audience can load it. For mainland-China audiences raw.githubusercontent.com is often blocked — prefer the project's own site.
   • Check .gitignore doesn't exclude the asset path.
   • If there's a hosted demo, make the visual a link to it, so the most clickable thing on the page is also the fastest way to try it.
6. Three bullets — benefits first, each with a bold lead-in and the how after a dash. Keep each to about one line on a phone.
7. Quick start — the shortest real path to the aha moment in the brief, not just to "it installed".
   • If a hosted version needs no sign-up, that link is the quick start: put it first, the install block after it.
   • Otherwise one code block; three commands at most before a "Full install" link.
   • If the headline feature needs an input (a file with a diagram, a sample playlist link), provide one.
8. Requirements line — one line naming any non-obvious runtime need: a browser, GPU, Docker, an OS limit, an account or paid API key. Visitors forgive a dependency they were told about.
9. Disclaimer (only for projects built on other platforms, media or personal data) — the brief's standard disclaimer: not affiliated with X; what it does and doesn't do.

Below the fold, make sure these exist (add short sections if missing): Why (honest contrast with alternatives, dated), Usage/Examples, FAQ (optional), Contributing, License. Remove launch scaffolding visitors shouldn't see (links to "launch copy", internal checklists), and re-check any comparison table: every ✅ must be fully true.

Language twins

Create a twin only if you'll post in channels whose language differs from the README's: README.zh-CN.md for an English README going to V2EX/HelloGitHub/即刻, README.en.md for a Chinese README going to Hacker News/Reddit. Skip it if the README already matches every target channel. If git history shows the author removed a twin, ask before adding it back (with no human available, don't add it back — record the question in decisions.md). Link both ways at the top: English | [简体中文](README.zh-CN.md).

GitHub always opens README.md, and many visitors decide before they notice a small language link (a heuristic from our own launch). If the first channels speak the twin's language, also put one line in that language right under the tagline — what it is, then a link to the twin — e.g. **中文用户**：一句话说明 → [看中文说明](README.zh-CN.md). Keep the full-width colon outside the **: GitHub won't close bold right after it when Chinese text follows.

• Write the twin natively: short sentences, concrete pain points, 「适合谁 / 不适合谁」.
• Keep the code blocks identical.
• In Chinese text use full-width punctuation and a space between Chinese and Latin words/numbers (中文 English 混排 like this).

Output

1. Show the user the new first screen as a diff or side-by-side.
2. After approval, edit README.md (and create the twin if requested). If approval can't happen now, write the proposal to .megaphone/readme-first-screen.md instead.
3. List what the user has to do: record the visual, run the quick start on a clean machine, set the repo description (≤ 160 characters) and topics (add specific ones; don't remove relevant existing topics — GitHub allows 20), set the homepage, upload a social preview image (1280×640).

Example first screen

# Megaphone

Launch your open-source project the way a marketer would — even if you've never done it.

[![License: MIT](https://img.shields.io/badge/license-MIT-blue)](LICENSE)

English | [简体中文](README.zh-CN.md) · [Try the checker →](https://2104178150-ai.github.io/megaphone/)

![Megaphone checker scoring a repo](docs/preview.svg)

- **Know if you're ready** — blockers, risks and a 0–100 launch score
- **Posts that fit each channel** — Show HN, Reddit, V2EX, HelloGitHub, 小红书…
- **See what worked** — stars and referrers lined up against your launch log

```bash
npx skills add 2104178150-ai/megaphone
```

Needs: an AI coding agent that supports skills (Claude Code, Codex, Cursor…). The web checker needs nothing.