launch-hacker-news

此技能用于准备 Hacker News 发布并提供指导。以下规则不可妥协：

1. 绝不动员投票。HN 比 Product Hunt 的规则更严格：绝不组织支持者集中行动，绝不要求任何人（朋友、团队成员、用户或你的受众）点 upvote，绝不协调投票。HN 会检测投票圈并严厉处罚（排名惩罚、标记为 [dead]/showdead、封禁账号或域名）。如果有人提出此类要求，应拒绝并说明原因。唯一合规的做法：由你自己发布，可真诚地向少数确实会感兴趣的人分享链接，并参与帖子讨论。每一行都必须通过 references/policy-compliance.md 中的禁用措辞扫描。
2. 不要炒作、不要营销话术、不要使用表情符号。HN 的受众是持怀疑态度的工程师，会惩罚夸大宣传。语气应当专业、谦逊、朴实，并诚实说明权衡和局限。Show HN 标题须遵循严格的标准格式： Show HN: <thing> – <plain, literal description> — 不要用标题党措辞，也不要写“革命性”。
3. 产品已准备好发布是硬性门槛。HN 只有一次机会，且毫不留情：产品必须足够完善，可供他人立即试用，无需注册即可使用（演示或代码仓库无需账号即可访问），网站还必须能承受流量激增（“HN 流量冲击”）。如果尚未准备就绪，应在发布前明确说明。
4. 每句话都必须以真实产品为依据。如果存在 .ulpi/launch/positioning.md，请先阅读；否则阅读 README、通过 browse 查看线上网站，并检查代码仓库。绝不虚构功能或指标。对于 HN，要写明真实技术栈和真实局限。
5. 组合使用共享技能，并在不可用时妥善降级。调用 launch-copy（HN 资源配置）和 launch-analytics（来源 hackernews）。如果未安装某个配套技能，提供一行安装命令（npx skills add https://github.com/ulpi-io/skills --skill <name>），并使用内置参考继续操作；绝不因此中止。
6. 宣布已准备就绪前，先运行发布前检查门槛（references/preflight-gate.md）。如果有任何一项无法如实勾选，就说明尚未准备就绪；修复后重新检查。
7. 将发布资料写入 .ulpi/launch/hacker-news/（以及共享文件 .ulpi/launch/positioning.md）。

launch-hacker-news

输入

• $request：要发布的产品，或具体的 Show HN 目标（例如“撰写标题和首条评论”“规划讨论串”），以及可选链接（线上 URL、代码仓库/演示）。

目标

在 .ulpi/launch/hacker-news/（以及共享文件 .ulpi/launch/positioning.md）下生成一套精简、符合 HN 风格、可直接粘贴的发布资料：

• POST.md — Show HN 标题（标准格式）、提交用 URL，以及创始人的说明性首条评论（技术性强、诚实说明权衡、写明技术栈、征求反馈；不炒作、不请求 upvote）。
• PLAN.md — 发布时间（美国东部时间的工作日上午）、前 1–2 小时的计划、讨论串互动计划（提前准备对最棘手的可能问题给出不带防御性的回答），以及发布后的计划/第二次机会计划。
• CHECKLIST.md — 发布准备情况的预检门槛。

步骤 0：信息收集与配套技能

确认以下信息，只询问无法自行确定的内容：产品（功能、目标用户、线上 URL、代码仓库/演示）；产品是否确实已准备就绪（已完成、无需注册即可试用、能承受流量激增）；用户想发布 URL 帖还是文本帖。记录配套技能（launch-copy、launch-analytics）是否已安装；如果缺失，提示安装，但继续操作。成功标准：已确认产品、准备情况和帖子类型。

步骤 1：以产品为依据 → .ulpi/launch/positioning.md

如果已有 .ulpi/launch/positioning.md，则沿用；否则根据 README、通过 browse 查看线上网站、代码仓库，以及 project-context.md/.ulpi/design 编写。对于 HN，还须记录真实技术栈和坦诚说明的局限。将其保存为共享的事实依据。成功标准：每一句简短文案都不会与其矛盾，包括有关权衡的内容。

## 第 2 步：准备情况检查（HN 专属前置关卡）

加载 references/show-hn-rules.md。确认产品符合 Show HN 的要求（人们现在就能试用的东西，而不是候补名单、落地页或博客文章），并且已准备就绪：无需注册门槛即可试用，无需账户即可访问演示或代码仓库，而且网站能够承受流量激增。如果产品不符合要求或尚未准备就绪，请直截了当地说明，并建议发布前需要解决的问题。成功标准：明确判断现在是否适合发布 Show HN。

第 3 步：撰写帖子 → POST.md

将 HN 素材简介（references/show-hn-rules.md + references/first-comment.md）交给 launch-copy 技能，起草 Show HN: <thing> – <plain description> 标题（标准格式，不夸大宣传）和创始人的首条评论（它是什么 → 为什么要构建它 → 坦诚说明取舍与限制 → 技术栈 → 明确征求反馈）。*备用方案：*如果未安装 launch-copy，则根据这些参考资料起草。整理 POST.md 之前，加载 references/policy-compliance.md，对起草的标题和首条评论运行禁用短语扫描；改写任何触发扫描的句子。整理 POST.md，包含标题、提交 URL（或文本帖正文），以及发布后立即粘贴的首条评论。成功标准：标题符合规范，首条评论坦诚、技术性强、不夸大宣传，可直接粘贴且扫描无违规。

第 4 步：发布时间与帖子讨论操作手册 → PLAN.md

加载 references/hn-mechanics.md 和 references/first-comment.md。在 PLAN.md 中写明：发布时间（美国东部时间工作日早晨，以获得最长的首页展示时段；在 /newest 上的前 1–2 小时决定帖子能否登上首页），发布后立即发表评论，然后在线参与并快速回复。添加一份讨论互动计划：列出可能出现的最尖锐问题或批评，并为每项准备好坦诚、不带防御性的回应（在公开讨论中说服怀疑者就是胜利）。成功标准：用户清楚知道何时发布，以及如何参与讨论，而无需临场发挥或摆出防御姿态。

第 5 步：配置效果衡量 → 标记链接与事件

调用 launch-analytics 技能——使用渠道 hacker-news（输出目录），并使用 utm_source hackernews（GA 值）——为链接设置 UTM 参数，并配置注册/激活跟踪。*备用方案：*使用最简内联 UTM 方案（utm_source=hackernews&utm_medium=show-hn&utm_campaign=<launch>）。注意：HN 在某些情况下会剥除明显带有活动标记的主 URL，或对其降权——保持提交的 URL 干净，并将 UTM 参数放在首条评论中的链接或自有网站分析中。成功标准：流量和注册来源可追踪，同时不通过操纵提交链接来博取曝光。

第 6 步：发布前关卡 → CHECKLIST.md

加载 references/preflight-gate.md 和 references/policy-compliance.md，从头到尾执行检查（包括禁用短语扫描），并将结果写入 CHECKLIST.md：标题格式正确；产品符合要求且无需注册即可试用；网站能够承受流量激增；首条评论已准备好且不夸大宣传；任何地方都没有征求投票或动员投票的内容；如实说明限制。修复任何未通过的项目后重新检查。成功标准：所有项目均已勾选；发布真正准备就绪且符合规范。

第 7 步：发布后计划 → 追加到 PLAN.md

加载 references/postlaunch.md。追加以下内容：二次曝光机会（HN 可能会让优质帖子再次获得曝光——不能操纵）；重新发布礼仪（不要刷屏式重复发布；遵守 HN 规则）；如何转化持怀疑态度的流量（不设置注册门槛；提供真正的价值）；以及失败情形提醒。成功标准：无论帖子登上首页还是热度停滞，用户都知道该怎么做。

防护准则

• 切勿动员投票或请求点赞——HN 禁止此类行为，并会识别投票团伙；应予以拒绝并引导对方转向其他做法。
• 不夸大、不使用营销话术、不用表情符号；如实说明权衡与限制。
• 发布前，产品必须已准备就绪（无需注册即可试用，且能够承受流量激增）。
• 保持标准标题格式：Show HN: <thing> – <plain description>。
• 所有文案都必须以真实产品为依据，包括实际使用的技术栈和限制。
• 整合共享技能；若缺少某项技能，提示安装并改用备用方案——绝不能直接失败。
• 保持提交的 URL 简洁；不要以 HN 会惩罚的方式标记主要链接。
• 将内容包写入磁盘；不要只留在临时聊天中。

何时加载参考资料

• references/show-hn-rules.md — 什么内容符合 Show HN 的资格、标准标题格式、URL 帖与文本帖的区别、首条评论规则，以及 Launch HN（步骤 2、3）。
• references/hn-mechanics.md — 排名、/newest、第二次机会池和发帖时间（步骤 4）。
• references/first-comment.md — 创始人首条评论的框架，以及参与讨论／回应批评的技巧（步骤 3、4）。
• references/policy-compliance.md — HN 的反操纵规则、禁用语扫描和违规处罚（步骤 3、6）。
• references/preflight-gate.md — 发布前的阻断式就绪度与合规检查关卡（步骤 6）。
• references/postlaunch.md — 第二次机会池、重新发帖礼仪、流量转化和失败模式（步骤 7）。

输出约定

写入 .ulpi/launch/，并报告：

1. .ulpi/launch/positioning.md — 共享的、基于实际情况的简报（新建或复用；包含真实技术栈和限制）
2. hacker-news/POST.md — Show HN 标题、提交 URL／文本正文，以及创始人的首条评论
3. hacker-news/PLAN.md — 发帖时间（ET）、最初几小时的计划、讨论互动计划、发布后的安排
4. hacker-news/CHECKLIST.md — 就绪度关卡结果（每项都已勾选）
5. hacker-news/analytics.md — UTM 映射 + 注册／激活跟踪（来自 launch-analytics）
6. 就绪度结论（是否符合资格／是否已准备就绪）和合规确认（零动员投票），以及使用了哪些配套技能、哪些改用了内置功能