Run First: Launch Contract
Before giving channel recommendations, output the Go / Fix / No-Go table and check: positioning, stranger Quick Start, reproducible Demo, License/security/privacy, launch-week response owner, and activation and commercial follow-through after Star. If any critical item is No-Go, fix it first; do not use volume to cover up product problems.
Unify the source TODO table into 5 views:
- Research table: ICP, community rules, recent high-quality content, risks, verification date.
- Content table: native angle, evidence, assets, CTA, approval, status.
- Distribution table: Owner, account, local time and time zone, UTM/source, actual link.
- Data table: baseline, 2h, 24h, 72h, 7d, cost, conclusion.
- Control table: dependencies, Go/No-Go, incident owner, stop conditions, retrospective date.
Unify the funnel as 曝光 → repo 访问 → install/quickstart → activation → D7 → contributor/qualified lead → paid. Star is only a developer interest signal. When native metrics are missing, write
数据不可用, and do not infer from impressions or engagement.
Red lines: do not buy Stars/accounts, do not manipulate rankings or coordinate fake Upvotes, do not hide paid collaborations, do not mass harass, and do not let AI impersonate real people participating in communities. Check the rules of Reddit/HN/Discord/groups one by one and disclose affiliations.
When to Use
- "I want to launch an open-source project; how do I start from 0?"
- "GitHub star growth is stuck at xxx and not moving"
- "How do I find developer KOLs to collaborate with?"
- "How do I post on Reddit / HN without getting banned?"
- "How do I build a dev.to / Zenn / CSDN content matrix?"
Core Framework (3 Stages)
Stage 1: Pre-launch (T-30 to T-0)
- README is ready (English-first, first-screen screenshot understandable in < 3s)
- Demo video ≤ 60s, with subtitles
- License chosen correctly (MIT/Apache-2/AGPL each have pitfalls)
- 3-5 early-bird maintainers / contributors
- Community channels in place (Discord or Telegram, English-first)
Stage 2: Launch (T-0 to T+14)
- Post on Product Hunt (in coordination with
gr-ph-launch） - Hacker News Show HN (only when there is genuine technical novelty and the team can answer questions online; verify the posting time against recent similar posts)
- Reddit: choose 3 relevant subs (r/selfhosted / r/programming / niche technical sub)
- Post in-depth technical articles on Dev.to / Zenn / CSDN
- Find 3-5 KOLs to repost (prioritize activity level > follower count)
Stage 3: Growth (T+14 to T+180)
- 1 technical blog per week (in coordination with
gr-blog-post） - GitHub Issues → content material (turn user questions into FAQs)
- Send 1 update per month (email list + Discord)
- Overseas localization (Japanese and Korean first, in coordination with the gr-blog-post i18n process)
Scenario Themes and Collection Validation
When post-launch content is scattered and cannot be reviewed, use scenario campaign and Web/CLI collection tables. Connect official accounts, creators, and communities around a single user task, retain topic and channel identifiers, and decide whether to continue, adjust, or stop based on real conversion and cost. The existing funnel definitions remain unchanged; what is added is data collection testing and observable scope, and retention cannot be inferred from an uninstrumented CLI.
In-depth reference
All details, KOL lists, messaging templates, and case libraries are in the upstream repo:
📂 https://skills.sh/Gingiris-1031
references/preparation.md— Complete pre-launch checklistreferences/channels.md— Distribution channel matrixreferences/templates.md— KOL outreach messaging / Reddit template / HN Show HN templatereferences/seo-geo-guide.md— Open source project SEO/GEO
On the first call, Claude should fetch these files as in-depth reference.
Cascading recommendations
- Stage 1 complete →
gr-ph-launch(all go through the PH launch process) - Stage 2 Show HN succeeds →
gr-seo-patroladd monitoring " github" - Stage 3 needs content production →
gr-blog-post - Discover a competitor's new play →
gr-competitordig deeper
Star geographic distribution & launch timing
- The star share from any single country/region must not exceed 20%, otherwise it is hard to get onto GitHub Trending.
- Tools:star-history.com(growth trends),OSS Insight(country distribution, developed by Chinese developers)
- Launch timing:In the first week, do only overseas promotion, and only in the second week do domestic promotion. Reversing the order will break the distribution.
- AFFiNE real case: it got 6,000 stars in the first week of open source and deliberately did not post on WeChat Moments / enter domestic communities.
README optimization points
- No more than 8 screens, developer documentation should be linked separately and not stuffed into the README
- adda small animated image reminding people to star(analogous to Bilibili's one-click triple action; users need to be reminded)
- backlinks loop: all outbound links (official site/blog/docs) must be able to link back to GitHub
PR article strategy
- Prepare a complete article explaining the project's advantages (official site Blog / Medium / dev.to)
- Purpose: give everyone who wants to help you spread the word a gun
- Case: a German user proactively posted in more than 40 forums without saying hello first — they were able to post because there was a reference article
Competitor follower direct messages
- Send direct messages to Twitter followers of competitors (Notion / Miro, etc.)
- Real-world data: several hundred direct messages → several hundred star conversions
- Prioritize users who complain about competitors, as they already have switching intent
Anti-patterns
- ❌ Star farming (GitHub can detect it quickly, and the consequence is that you become unsearchable)
- ❌ Posting once on Reddit and then running away (communities dislike it, and the risk of being banned is high)
- ❌ Posting an English project in Chinese communities first (unless your target is Chinese users, the order should be English > multilingual > Chinese)
- ❌ Putting too many emoji / badges in the README (reduces credibility)