launch-posts
Skill5 starsChanged 32 days agoMITView on GitHub
Pick the channels where a project's audience actually is — developer communities for developer tools, the platforms end users already browse for apps, plugin directories for extensions — and prepare a rule-checked draft for each, or, where the platform wants the author's own words (Show HN, a DEV launch article, Lobsters, V2EX, 掘金 articles and 沸点, awesome lists that refuse LLM-written entries), a fact sheet the author writes from: Show HN, Reddit, Product Hunt, X/Twitter, DEV, Lobsters, awesome lists, newsletters, V2EX, HelloGitHub, 阮一峰科技爱好者周刊, 即刻, 小红书, 掘金, 知乎, B 站 and more. Use when the user wants to announce or promote a project or app, write a Show HN / Reddit / Product Hunt post, or says 写推广文案 / 发帖推广 / 发 V2EX / 投稿 HelloGitHub / 小红书怎么发.
In this repository6 other files it gives its agents.
- launch-auditSkill
- launch-planSkill
- launch-positioningSkill
- launch-readmeSkill
- launch-reviewSkill
- launchSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 4 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 15
Read these first; ask only for what's missing and record answers (or, with no human available, your assumptions) in .megaphone/decisions.md.
- Distinctive: line 35
Read channels/README.md and start from where *this* audience is: developer tools → HN, Reddit, language communities.
- Distinctive: line 45
Audience fit: do the people here have the problem?
- Very specific: line 140
Window: keep it in the playbook's own timezone.
- Distinctive: line 145
Never answer a legal question with a guarantee.
- Distinctive: line 171
Native language and tone: Write each post from scratch in its channel's language and register (HN: plain and technical.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Launch posts
Each channel has its own audience, rules and taboos. A post that wins on Show HN gets removed on r/programming and ignored on 小红书. This skill picks channels on purpose and prepares one native draft per target — or, where the platform asks for the author's own words, the facts the author writes from.
Inputs
Read these first; ask only for what's missing and record answers (or, with no human
available, your assumptions) in .megaphone/decisions.md.
.megaphone/brief.md: one-liner, audience, bullets, origin story, dated contrast, Claims we won't make and the standard disclaimer. If it's missing, run../launch-positioning/SKILL.mdfirst (a quick brief is enough)..megaphone/audit.md: open blockers and Risk & readiness (third parties, other people's data, capacity, reachability). Drafting can start with blockers open; when posts can go out is decided by the gate in../launch-plan/SKILL.md..megaphone/decisions.md: is the user the author, their accounts and how established, which languages they can read and reply in, where they plan to launch first, timezone and free hours, and where the project has been posted before.- The README (quick start, visual, hosted link). If
.megaphone/readme-first-screen.mdexists and hasn't been applied yet, draft against that proposal and say so in the channel table — posts must match the README visitors will land on. - Any launch copy already in the repo (
docs/launch*): reuse what's accurate and note where you differ.
Step 1 — Choose channels
Read channels/README.md and start from where this audience is: developer tools → HN, Reddit, language communities; end-user apps → where those users already browse (小红书, 即刻, B 站, Product Hunt, r/SideProject…). For a plugin or integration, the host app's channels (plugin directory, release notes, forum) often beat everything else: see ecosystems.md, and ask the host's maintainer before posting in their space. A regional channel with no playbook (e.g. Zenn for a Japanese user) can be a candidate; read its own rules first.
Mark each candidate ✅ / ⚠️ / ❌ on:
- Audience fit: do the people here have the problem?
- Format fit: can it be shown the way this channel likes, with assets ready in time (a no-sign-up demo for Show HN, 3–6 images for 小红书, a personal story for 即刻)?
- Account fit: does the user have an account that won't be filtered (new ones often are on HN, Reddit and V2EX), in a language they can read and reply in? Submission channels usually need only a GitHub login or email; a language the user can't read is ❌.
Draft every channel with no ❌ and at least two ✅, up to six posting channels (if
more qualify, keep the six with the most ✅ and say which you cut). Compounding
channels — awesome lists and newsletters, including HelloGitHub and 阮一峰周刊 — are
extra, drafted whenever they pass the same test. GitHub itself (topics, social preview, a
release) needs no post: add its to-dos from github-native.md
to the table. If the user isn't the author, skip Show HN (it's "for something you've
made"). If authorship is only unconfirmed (no human to ask), keep the row as
blocked: confirm authorship and write the fact sheet anyway. A host or community space
that passes the test but needs a maintainer's or moderator's OK first
(ecosystems.md) gets the decision ask first instead of a post:
save the ask, drafted from that file's template, as posts/<channel>.md with an ## Ask
section (to whom, where), Status ask drafted; user sends. It doesn't count toward the six
until they say yes; when the user reports a yes, rerun this skill for that row and write the
post (if that makes seven, drop the one with the fewest ✅ and say so).
Repost check before HN or Reddit. HN: open
https://hn.algolia.com/api/v1/search?query=github.com/OWNER/REPO&restrictSearchableAttributes=url&tags=story,
then search the project name at hn.algolia.com. Reddit: search reddit.com and each target
subreddit for the repo URL and name; if Reddit blocks automated requests, write
[TODO: check for earlier posts]. HN allows a small number of reposts only if the story
hasn't had significant attention in the last year or so, and never delete-and-repost
(FAQ); each subreddit sets its own rule. After
a big earlier thread, skip the channel or wait for a major release.
Save the table to .megaphone/posts/README.md (in the user's language) and show it in chat:
# Channels — <project>
README assumed: current README / proposal in readme-first-screen.md (not applied yet)
| Channel / target | Audience | Format | Account | Decision | Why (incl. repost check) | File | Status |
|---|---|---|---|---|---|---|---|
| Show HN | ✅ | ✅ | ✅ | author writes | no earlier submissions (hn.algolia.com, <date>) | hacker-news.md | fact sheet ready; author to write |
| r/commandline | ✅ | ✅ | ⚠️ | draft | none found | reddit-commandline.md | [TODO] origin story |
| r/ghostty | ✅ | ✅ | ⚠️ | ask first | host community, no showcase thread found | reddit-ghostty.md | ask drafted; user sends |
| 小红书 | ✅ | ⚠️ | ❌ | skip | user has no account | — | — |
| GitHub itself | — | — | — | to-dos | <topics, social preview, release> | — | — |Step 2 — Prepare one file per target
Name files after the playbook: one per posting target (posts/hacker-news.md,
posts/reddit-commandline.md, posts/reddit-golang.md), one per submission channel
with a section per target (posts/awesome-lists.md, posts/newsletters.md; HelloGitHub
and 阮一峰周刊 have their own playbooks and files). Follow the playbook in channels/:
title rules, length, language, links, first comment, pitfalls.
Author-written channels. Some platforms ask for the author's own words, and their
playbooks say so: Show HN (hacker-news.md), a DEV launch
article (dev-blogs.md), the Lobsters title and comment
(lobsters.md), V2EX (a written rule bans AI-generated text in topics and
replies — v2ex.md), 掘金 articles and 沸点 (AI-generated technical content counts
as plagiarism and is never recommended — juejin.md), and awesome lists whose rules refuse LLM-written
entries or PRs (awesome-lists.md). For these, don't write
prose: use the same file and header, but replace ## Title / ## Body with
## Facts for the author (bullet facts for each part of the playbook's outline, [TODO]
where only the author knows) and keep Likely questions as facts to answer from, not
scripted replies. Their Status is "author writes" until the user says the text is done.
For every other channel, write:
# <Channel> — <target> — draft
Where: <exact URL, node, subreddit or submission form>
Window: <the playbook's window in the playbook's own timezone, e.g. "08:00–10:00 PT (heuristic)", or "no data — chose <X> because <Y>">
Account: <which account posts>
## Title
<only if the channel has titles>
## Body
## First comment / follow-up
<only if the playbook uses one>
## Likely questions
- "<predictable objection>" — <short honest answer, or [TODO: ask the author]>
## Checklist before posting
- [ ] Rule check: <the 1–3 rules most likely to get this removed: playbook + this target's own rules (sidebar, CONTRIBUTING.md), or [TODO: read <where>]>
- [ ] Risk check: nothing from brief → Claims we won't make; disclaimer included (if the project touches other platforms)
- [ ] AI disclosure: <what this channel expects, e.g. 小红书: declare AI help with the publish page's AI-content declaration; or "none required">
- [ ] Links work and are reachable for this audience
- [ ] Assets ready: <images / GIF / video this post needs>
- [ ] Reply window free (see plan.md)(Author-written files keep the same checklist, plus - [ ] The author wrote the text in
their own words.)
- Window: keep it in the playbook's own timezone.
launch-planconverts it to the user's local date and time inplan.md, so moving the launch (even across a DST switch) never leaves stale times in the posts. - Likely questions: 3–5 objections this audience will raise ("why not X?", "why does it need Y?", "is this allowed?", "what about my data?"), answered from the repo and brief. Never answer a legal question with a guarantee; point to the disclaimer.
Writing rules for every channel
- Lead with the problem or the result, not the tech stack (that comes second).
- Say you made it (or your relation to it). Many subreddits require it; all expect it. In neutral-blurb formats (HelloGitHub, 阮一峰周刊, newsletters, awesome lists) disclose it only the way the form or list asks, e.g. 【开源自荐】 in a 阮一峰周刊 title.
- Label AI help where the channel asks for it. These drafts are AI-assisted. 小红书 requires AI-assisted content (including AI-polished text) to be declared at publish time; some subreddits and DEV have rules on AI-written posts; V2EX bans AI-generated text in topics and replies, and 掘金 never recommends AI-generated articles (fact sheet only for both — see v2ex.md, juejin.md). Follow each playbook, and when in doubt, let the author rewrite it in their own words.
- One link: the one this channel's readers can use — the hosted app for end users, the
repo for developers, none where outbound links are banned (小红书's 2025 交易导流 rules, up to account bans;
say what to search for, as its playbook does). Add the repo as a second link only
where the playbook template has a separate repo or source line (
Source:,Repo:,开源地址,仓库链接…). - Be specific and modest. Real numbers and limitations beat adjectives; contrast claims come only from the brief, with their date.
- Say what it doesn't do yet, except in neutral-blurb formats, which you write the way the editor or list would print them.
- Never ask for upvotes, stars or likes, or coordinate friends to vote: it breaks HN, Product Hunt and Reddit rules and gets posts killed. (A quiet one-line note in the project's own README or tool is fine; asking in posts, DMs or in return for help is not.)
- Native language and tone. Write each post from scratch in its channel's language and register (HN: plain and technical; 即刻: personal; 小红书: visual, benefit-first).
- No two posts identical. Reuse facts, not sentences.
- The author's voice comes only from the author. "I built it because…" comes from the
brief's origin story or the user's own words in
decisions.md; otherwise write[TODO: in your words, why you built it]. Unknown numbers stay[TODO]too.
Step 3 — Hand off
Summarise in chat: the channel table, where each file is, which drafts are ready to paste,
which are fact sheets the author writes from, which still have [TODO]s (and what each
needs), the ask first messages the user sends, and the assets to make. Hand off to ../launch-plan/SKILL.md for order, dates and
reply windows. Remind the user that they publish manually, and that right after each post
goes live they add a row to .megaphone/log.csv: date as YYYY-MM-DD, time as 24 h
HH:MM in their timezone, channel as the file's base name (hacker-news,
reddit-commandline, v2ex), and the post's URL — so launch-review can attribute
results.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

