开源项目发布/Show HN 前用：完成名称与许可证清理…

当你要公开发布、宣布、开源或 Show HN 一个仓库，或想上 GitHub Trending、获取首批用户/Star、策划 Product Hunt/发布周、诊断发布为什么失败时使用。

适用场景

解决思路

1. 访谈时一次只问一个问题，按顺序问，尽量给多选项；能命名受众、锚点渠道和目标后停止，其余推断并稍后确认。
2. 按顺序覆盖这些访谈问题：项目是什么、用户前五分钟会做什么；目标采用者是个体开发者还是需在公司内推动审批的工程师（两者都合法，会影响要交付的材料而非是否发布）；替代/竞争对象，包括“手写”；发布目标（用户、贡献者、招聘信号、商业产品漏斗、公司品牌可信度）；是否有公司背景、是否有闭源/付费/计划收费；当前状态（名称清理、许可证、README、安装路径、文档、演示、测试、SECURITY.md、注册表发布）；维护者已有账号且有历史的社区；结果截止日期是外部固定（会议、融资公告、竞争对手）还是可移动；目标是一次性发布窗口胜利还是六个月后仍能带来采用者的复利资产；精力上限（发布日及后一周维护者小时数、谁可拥有渠道、什么完全不碰）；已发布内容（早前帖子、私有 beta、内部公告）。
3. 记录访谈答案后再规划；若环境有持久记忆，存进去，让后续发布复用，第二次发布不要从零开始。
4. 用答案改计划：固定近期日期删除发布周的长文；复利任务把长文提到次级社区之前；精力上限低于约一天时收缩为注册表加锚点帖子，其他不做。
5. Step 1 先清名称和许可证：两者都是改名触发器，不是可修复缺陷。
6. 做商标清理检索，覆盖所有目标司法辖区，检查语音、视觉、概念相似，不只完全相同匹配。
7. 在名称公开出现前，先拿到域名、代码托管组织名和社交账号（secure first, release later）。
8. 记住免费分发不是抗辩：无费在互联网分发本身可能构成商标商业使用（Planetary Motion v. Techsplosion, 261 F.3d 1188），项目会因此收 cease-and-desist 并在已可见后改名。
9. 任何可争议冲突都在发布前改名，不要带着风险上线。
10. 同一轮定下许可证和 CLA-vs-DCO 立场；已被采用项目再改许可证会可靠触发社区 fork。
11. Step 2 跑就绪门禁：按 readiness-checklist 给仓库打分，区分 blockers 和 boosters。
12. 字面执行阈值：设定日期前每个 blocker 必须通过；一个未关闭 blocker 就移动发布日期；boosters 从不移动日期。
13. 外部日期固定但 blocker 未清时，明确说明，并提出能通过的最小范围（例如只宣布仓库，不带 benchmark 声明）。
14. 用冷启动跑决定门禁，不靠意见：找从未用过项目的人只按 README 在干净环境操作，不向维护者提问。
15. 如果能执行命令，自己在全新目录做冷启动，记录每个需要猜测的点；每个猜测都是缺陷，修复后重跑。
16. 通过条件：冷读者无需帮助，在项目声称的时间预算内达到首次成功。把“库五分钟、服务十五分钟”当自设基线，不是行业标准；用 README 自己承诺的预算替换。
17. Step 3 打磨定位：一行简介写成 `<name> is a <category> for <audience> that <capability the alternatives lack>`；类别优先，读者先归档再评估，拒绝类别的项目会被归为营销。
18. 回答开发者十秒内会问的三个问题：它是什么？我有这个问题吗？为什么不用我已经在用的东西？
19. 明确写出“为什么不用 X”的答案，点名真实替代品以及它们更好的地方；回避会被默认输给现有方案，因为保留现有方案零成本。
20. 按 Hacker News 给发布创始人的指导控制语气：不要营销、销售或 PR 风格；像同行一样对读者说话；不用最高级（fastest、biggest、first、best）；谦虚措辞更强；保持 humble。
21. 按 announcement-examples 的可信度准则检查草稿：公平命名替代品；在别人发现前公布限制；benchmark 要么给方法和复现命令，要么删掉数字；链接代码而不是描述代码；诚实说明成熟度；若公司背后有项目，预先披露商业边界。
22. 用维护者自己的声音写：第一人称、为什么存在、难在哪里、砍掉了什么；营销代笔的草稿发布前过一遍 humanizer skill，否则像新闻稿会暗示工程师没被允许参与。
23. Step 4 选发布形态：单点尖峰：一个项目一个主故事，Show HN 作锚点，Product Hunt 作可选次级；这是默认，几乎适合所有独立项目。
24. 发布车队：多日或多周序列，把同一个故事反复营销给连续受众；Supabase Launch Week 和 Cloudflare Innovation Weeks 是两种记录模型；理由是你可多次发布新功能，触达忘了、忽略或错过前几次的人。
25. 按每维护者小时产出排序：单点尖峰 > 低于阈值的车队；车队把一周小时乘以天数，只有每天都有真实故事时才回本。
26. 仅当超过阈值才跑车队（本技能设定，非公开规则）：至少三个可宣布项、日历上有会议或固定日期、有人员每天指定 owner；低于此，车队会稀释成几个没人理会的帖子。
27. Supabase 故意不为 Launch Week 扣住功能：早发布，之后再以完整 write-up 重新宣布；所以该模型需要量，不是保密。
28. 发布形态决定 Step 5 如何排序：尖峰一次发射锚点和放大器；车队每天用新故事重复发射模式。
29. Step 5 排序渠道：选一个锚点渠道（受众已在那里评估新项目），其他都作为引流回锚点的放大；同时发四个“主”帖会得到四个死帖，因为每个讨论面都按早期互动密度排名。
30. 按每维护者小时产出从高到低花一周时间，不是从便宜开始。
31. 渠道行 1：注册表发布、release tag、仓库 description、topics、social preview；近零成本（分钟级，资产已存在）；决定其他行是否转化，安装命令失败会浪费计划带来的全部流量。
32. 渠道行 2：锚点帖、第一条评论、留在 thread；几乎一整天，主要是 presence 而非写作；贡献大部分发布结果，且不可重试——第一小时搞砸的 thread 到第三小时就死了。
33. 渠道行 3：次级社区，错峰发布，每次重写上下文；每社区一小时且不可压缩（粘贴宣传语会被删）；买锚点漏掉的生态受众。
34. 渠道行 4：维护者自己的账号；近零成本（一个已起草帖子）；买到维护者已有受众；没有受众则没有。
35. 渠道行 5：newsletters 和 curated lists；每 outlet 一小时，多数在窗口关闭后发布；买到 curator 裁量下的长尾到达。
36. 渠道行 6：长文 write-up（架构、战史、benchmark 方法）；一周，且落在空闲最少的一周；持久，一年后仍带来读者。
37. 分开读各轴：效率 `registry > anchor > secondary > own social > newsletters > write-up`。
38. 发布周工作量从重到轻：`write-up > anchor > secondary > newsletters > registry == own social`。
39. 窗口内 reach：`anchor > secondary > own social > newsletters > write-up > registry`。
40. 第 30 天后耐久性：`write-up > registry > newsletters > anchor > secondary > own social`。
41. 合规成本：`secondary > anchor > own social`（其他三行没有）。合规成本是 moderator 判断，不是费用；次级社区由人类读，检查发帖历史，可删帖封号；锚点有 flag 和 per-domain 惩罚，从外部看不见且比发布活得久。
42. 默认：行 1-3 就是发布。只有六小时的维护者做这些就停。有真实受众时加行 4；有第二个人能负责提交时加行 5；只在下面条件满足时加行 6。
43. 对答案排除的行，删除而不是降级；没有现有受众就删除行 4，而不是排最后，因为排在底部的行会作为发布日范围重新出现；没有第二个人同样删行 5；固定近期日期删行 6。
44. 这个顺序会饿死长文 write-up：页面最耐久资产每轮都输，因为花一周且落在最少小时的一周，在 thread 结束前没有产出。
45. 当访谈问题 8-10 显示目标是复利而非尖峰、差异化是论证而非 demo（新算法、反共识设计决策、迁移故事）、或日期可移动时，把长文提到行 3-5 之前；先写它，让它支撑第二周。
46. 这个排序是默认不是法律，要按已知上下文重排：已有 newsletter 或会议演讲把行 4 提到行 3 之前；某类别有一个主导 curated list 把行 5 提进发布周；写得快的维护者改变一周 write-up 成本。
47. 效率顺序不是发射顺序；本排序说小时花在哪，channel-playbook 里的时钟说每行何时发射，那个由机制固定。
48. 锚点帖存在前每个链接必须可解析；起草任何帖子前先读 channel-playbook，它覆盖每渠道规范、标题规则、Hacker News 与 Product Hunt 分工、什么会被 flag。
49. 为两类采用者构建不同资产；只服务一类会得到错误类型的胜利。
50. 个体采用把试用当 pitch：time-to-first-success、展示输出的 demo、zero-config 默认值。
51. 公司采用需要评估者可转发给审批人的页面：license compatibility、maintenance guarantees、security posture、release cadence、support。
52. 两套都不发，发布只会产生 stars 没有 deployments。
53. 如果 press 重要，约提前三周开始；Supabase 自己的说法是 press 需在计划 Launch 前最多 3 周组织。Embargo 和 exclusive 机制属于 `samber/developer-relations-skills@tech-press-relations`，不在这里。
54. 上述排序只覆盖发布窗口，稀缺资源是一周内小时数且注意力一次性。窗口关闭后，行 5 和 6 交给 `samber/developer-relations-skills@oss-distribution-strategy`，不要在这里重新计价。
55. Step 6 建 war room 并跑发布日：按 launch-day-runbook 构建 run of show：pre-flight checks；按锚点受众地理选择 posting hour；提供上下文的 first comment；response rotation；谁盯什么。
56. 按 GitLab 模型配人（唯一完整公开的发布日 playbook）。四个通用件：每渠道一个 named DRI；声明 response cadence，而不是 as needed；升级路径到能回答的工程师；明确谁可以权威发言。
57. 语气规则用三个词概括整套姿态：conveying without convincing。
58. 两条规则决定大部分结果：立刻发维护者自己的顶层评论：你是谁、为什么存在、底层有什么有趣、目前不做什么。
59. 第二条：在 thread 里待数小时，回答一切，包括敌意评论，不防御。
60. 发布后你唯一完全控制的变量是 availability。
61. 并行保留 triage lane：第一小时发现的安装路径损坏，同一小时修复并发布，并在 thread 说明；这比争论更快转化批评者。
62. 一类评论完全绕过 rotation：安全报告或类似安全报告。
63. 安全报告处理：停止公开讨论；把报告者指向 `SECURITY.md`；开 private advisory；在私有分支 patch；发布 advisory 并致谢报告者。
64. 协调披露只有在发布日前存在联系路径才有效；所以它是 Step 2 的 blocker，不是发布日反应。
65. Step 7 集中速度，绝不制造速度：发现面采样流量而非存量。GitHub Trending 按窗口内新增 stars 排名（today / this week / this month）并按语言过滤，所以项目的语言页池子远小于全局页，是首次发布的现实目标。选择公式未公开；把任何逆向工程版本当民间传说，绝不要承诺上榜。
66. 因此集中胜过分散：同样精力压到一天产生这些面奖励的斜率，一周滴灌没有。
67. 同一机制的另一半是硬边界：绝不拉票、要 star 或要评论，也绝不协调它们。Hacker News 声明请求 upvote 会让 submissions、accounts 和整个 domains 被惩罚；Product Hunt 按真实性给投票加权，不是原始计数。
68. 惩罚从外部看不见，所以团队可能一直跑这套玩法却不知道帖子为什么死。让同事“去看看”可以；让任何人 upvote 或 star 不行。发布日前对团队把区别说清楚。
69. Step 8 诚实测量：发布前一晚抓 baseline：stars、unique visitors、cloners、registry downloads（上一整周）、docs sessions、open issues、contributor count、referrers。
70. Traffic panels 只保留很短滚动窗口，未抓取的 baseline 不可恢复。
71. 读三个窗口（常规切分，不是标准）：Day 1 量 attention；Day 7 量 trial；Day 30 量 adoption。
72. 到 `references/measurement-plan.md` 看指标定义、目标设定方法和 funnel-stage 诊断表。
73. 把 stars 当最响但最无意义的信号。一个陌生人读了文档后开的 issue 胜过一百个 star；要配对的指标是 star 增长 vs unique cloners 和 downloads。前者尖峰而后者不动 = 公告传播了，项目没有。
74. 目标设为项目自身发布前 baseline 的倍数。流传的发布日每小时 stars、首页阈值或 day-1 download lift 绝对数字追溯到单一轶事和发布顾问主张；说明这一点，不要采用为 target。
75. Expected output：产出维护者无需你在场也能执行的 launch plan：`# Launch plan - <project>`，包含 Verdict go / go with reduced scope / not ready（列出 blockers）；Clearance 名称、trademark、license、CLA/DCO 状态；Positioning 一行简介、why-not-X、三个能 defend 的声明；Audience individual/company adoption，以及各自需要的 assets；Shape single spike 或 caravan，附理由；Channels anchor + amplifiers 按 outcome per hour 排序，然后 firing clock、每行 DRI、被删除行及原因；Run of show 发布日逐小时，包括 first comment；Measurement baseline 快照、day-1/7/30 targets、tracking method；Risks 什么会被 flag、坏掉或压垮，以及响应。
76. 逐节展示 launch plan，每节取得同意后再进入下一节；如果先把所有帖子写完，定位错误会传播到每一篇。
77. 避免常见失败模式：名称未清理就宣布——公开可见后改名会损失 URL、搜索历史和公告本身；在 Step 1 清理，或明确接受风险。
78. 避免：外部日期固定但有 blockers 未关就发布；应缩小范围，否则坏安装命令会成为置顶评论并在搜索结果中压过项目多年。
79. 避免：把平淡发布当运气差；重新发布前按 funnel stage 定位，见 measurement reference 诊断表。只有“渠道错了”才 justify relaunch；其他应修复 artifact。
80. 避免：死 thread 立刻重发。聚合器埋掉重复帖。Hacker News 只在故事“has not had significant attention in the last year or so”时允许少量重发，并有 moderators 用于重新浮现好提交的 second-chance pool。给他们发一次邮件是受认可的恢复路径；重新提交不是。
81. 避免：没人守场。在会议密集日之前发帖会死在评论里；移动时间。
82. 避免：赢错受众。企业型项目用个体开发者渠道会得到掌声没有采用；看 day-30 数字，不是 day-1。
83. 避免：第一周 burnout。表现过好的发布落在已经脆弱的一两人团队上。Tidelift 维护者调查（2020、2022）显示专业维护者 burnout 46%，广泛使用项目升至 58%，近 60% 退出或考虑退出项目。发布日前商定 triage trigger（issue templates、thread locks、临时 contribution freeze）和能守住的 response SLA，不要等溺水时再定。
84. References：pre-launch-timeline 是 8 周外分阶段序列：trademark、license、press、war room、freeze；readiness-checklist：blockers、boosters、cold-run protocol；channel-playbook：per-channel norms、HN vs Product Hunt、title rules、what gets flagged；launch-day-runbook：逐小时 run of show、DRI 模型、first-comment 和 response 模式；announcement-examples：弱 vs 强 one-liners、titles、comparison tables、first comments；measurement-plan：baseline capture、day-1/7/30 metrics、flat-launch diagnosis。
85. Related skills：readme-optimization 是 launch 指向的 README；developer-quickstart-guide 是 gate 测试的 first-success path；oss-license-strategy 是 Step1 假设已定的 license 和 CLA/DCO 决策；tech-press-relations 是 embargo 和 briefing 机制；oss-distribution-strategy 是发布窗口关闭后的渠道组合；open-source-company-strategy 是规划发布前先定什么开源边界。

适用边界 · 注意事项

• 不适用于发布窗口之后的持续分发；窗口关闭后应转用 `samber/developer-relations-skills@oss-distribution-strategy`。
• 不适用于不满足 caravan 阈值（少于三个可宣布项、无会议/固定日期、无每天指定 owner）时强行做多日发布周。
• 不适用于名称/许可证未清理或 readiness gate blockers 未通过却硬赶外部日期；应缩减范围或推迟。