open_source_launch_kit v1.0.0

name: open_source_launch_kit description: Turn an open source repo into a launch: positioning pulled from real proof in the code, a demo script and shot list, README copy that sells honestly, and platform specific posts for launch day. Use when a repo is going public, cutting its first release, or relaunching after a major overhaul, and when someone asks how to launch on Show HN, Product Hunt, Reddit, or socials without sounding like an ad.

Open Source Launch Kit

Purpose

Most open source launches fail quietly: a good tool, a vague README, one copy pasted post, and no proof anyone can check. This kit fixes the launch, not the code. It pulls positioning from evidence already in the repo, builds a short demo that proves the main claim, rewrites the top of the README around that claim, and writes a different post for each platform, shaped by that platform's actual rules.

It is distinct from release packaging. Packaging gets a private repo safely public (license, secrets, history). This kit assumes the repo can go public and answers the next question: why should a stranger care, how do you prove it in 90 seconds, and what do you say on each platform on the day.

Workflow

1. Extract proof before writing anything. Read the repo the way a skeptic would. List: what it does in one plain sentence, who it is for, the one workflow that works end to end today, real outputs or screenshots you can show, the license, and the honest limits. Every claim in every launch asset must trace to an item on this list. If a claim has no proof in the repo, cut it or build the proof first.
2. Write the positioning line. One sentence, in this shape: [Name] is a [category] for [audience] that [does the core job], [honest difference]. Worked example for a fictional tool: "Snaplog is a command line tool for developers who work across machines that makes shell history searchable, with every log kept in one local file and no account." Test it: could a competitor paste their name into the sentence and have it still be true? If yes, the difference is too weak. Sharpen it from the proof list, never from adjectives.
3. Audit the repo. Run python3 bin/launch_audit.py /path/to/repo (add --json for machine output). Fix every FAIL before launch day. The audit checks what a visitor checks in the first minute: a README with positioning prose, a copyable install or quickstart, usage or demo wording, visual proof, a LICENSE file, community health files, release notes, and a staged social preview image.
4. Rewrite the top of the README. GitHub's own guidance puts the same things first: what the project does, why it is useful, how to get started, where to get help, and who maintains it. Order the top of the README like this: name, positioning line, demo GIF or screenshot, install command, a 30 second quickstart with real output, what it does not do yet, then links to deeper docs. Long material belongs in docs, not the README. Then do the fresh clone test: follow your own README in a clean environment, word for word. If you get stuck, every visitor gets stuck.
5. Build the demo. Follow references/demo-script.md. Record a 60 to 90 second demo that shows the problem, the install, the core workflow with real output, one honest limit, and the invitation for feedback. Export a muted GIF cut for the README and a narrated cut for video platforms. Check both at phone size before launch day.
6. Cut the release. Tag a version and publish release notes that say what works, what is rough, and what to try first. With the GitHub CLI that is gh release create v1.0.0 --title "v1.0.0" --notes-file RELEASE_NOTES.md. Mark anything not production ready as a prerelease with --prerelease. A launch that points at an untagged main branch gives visitors nothing stable to try.
7. Write one post per platform. Use references/platform-posts.md for the rules and worked examples for Show HN, Product Hunt, Reddit, X, LinkedIn, and a build article. The non negotiables: Show HN requires something people can try, ideally with no signup barrier, a title starting with "Show HN", and no asking friends to upvote or comment. Product Hunt forbids asking for upvotes, so ask for visits and comments. Reddit expects genuine participation, disclosure that you built it, and each subreddit's own rules checked first. Check every platform's current rules during launch week, because rules change and old guides go stale.
8. Run launch day from the sheet. Fill in templates/launch-day-run-sheet.md the day before. Repo and release go live first, the anchor post second (the platform where the target users actually are), secondary posts after, each rewritten, none copy pasted. One person owns comments for the day. Log repeated criticism as issues, thank people specifically, and promise no dates.
9. Close the loop the day after. Post a follow up in the same places: what landed, what people asked for, what ships next. Triage new issues, label a few good first issues, record the real numbers with dates, and fix the README anywhere launch day proved it unclear.

Output Contract

• A proof list drawn from the repo, with every launch claim traced to it
• A one sentence positioning line that survives the competitor name swap test
• A launch audit result with zero FAILs, from bin/launch_audit.py
• A rewritten README top: positioning, demo, install, quickstart with real output, honest limits
• A demo script, shot list, README GIF cut, and narrated cut
• A tagged release with notes that name what works and what is rough
• One drafted post per target platform, each following that platform's current rules
• A filled launch day run sheet and a day after follow up draft

Operating Rules

1. Proof before copy. If the repo cannot show it, the launch cannot say it.
2. No vote, star, or upvote asks on any platform, phrased any way. Ask for tries, feedback, and comments instead.
3. Never copy paste one post across platforms. Each audience and each rule set is different, and readers can tell.
4. State limits in the launch assets, not after someone finds them. One honest limit builds more trust than five extra features.
5. No invented numbers. Installs, users, benchmarks, and speed claims appear only when they are real, dated, and reproducible from the repo.
6. Check platform rules live during launch week. A guide, including this one, is a starting point, not a substitute for the current rules page.
7. Launch day is for answering, not shipping. Do not push untested fixes in a panic. Post a clear note about a real bug first, then fix it properly.