产品发布时准备社区与目录提交包（Product Hunt…

当你要执行产品发布的社区/目录渠道时，按各平台官方规则生成逐平台提交包、分层目录波次和区域渠道矩阵，并做投票拉票等红线检查。

适用场景

解决思路

1. 确认发布事实：读取阶段/日期/窗口/禁发期、当前 manifest 版本与哈希，以及绑定到该哈希的 SHIP 结论；缺少已接受状态或哈希不匹配时标记为 Unknown/NEEDS_INPUT，不要据此提交。
2. 选择渠道矩阵：按受众匹配度从 channel-matrix.md 挑选平台，平衡自有/租用/借用渠道，仅在受众确实存在时纳入区域/中文渠道（即刻 / V2EX / 少数派 / 掘金 / 小红书类）；提交前用 WebFetch 核实每个社区当前规则，规则禁止本账号自我推广的渠道直接剔除。
3. 构建 Product Hunt 提交包：标语、图库素材清单、首条评论（maker comment）骨架（含故事与诚实的反馈请求）、发布日回复负责人；字段规格（字数限制、图库尺寸）引用 Product Hunt 官方提交文档并标注“需核实当前值”，不要凭记忆硬编码限制；文案来自 message house，任何产品或对比性声明只用已批准的 claims-ledger 措辞，新声明标 [needs source] 并通过授权 operation: propose 请求提交到 registry-events.py 写入 memory/events/claims.ndjson，绝不在此裁定。
4. 构建 Show HN 提交包：按官方 Show HN 指南要求的格式写事实性标题 `Show HN: <what it is, stated plainly>`，且必须是人们真正能试用的东西；不用最高级形容词、不用营销框架，正文说明它做什么以及如何构建；隐藏排名机制（口水战降权、二次机会池、发帖时段效应）标为 Estimated（社区传闻，minimaxir/hacker-news-undocumented），仅作预期参考，绝不作为提交标准或承诺结果。
5. 构建 subreddit 帖子：做逐版块表格（subreddit、其规则页原文的自我推广规则、要求的 flair/格式、账号历史期望），每行标注需核实当前值，并为每个版块写一篇原生风格帖子；版块规则含糊时先问版主，不要试探边界。
6. 规划目录波次：分层波次模式——第 1 波在 T-0 投少数高流量渠道，第 2 波在第 1 周投垂直/小众目录，第 3 波做长尾；该模式与分层为 Estimated（来源：coreyhaines31/marketingskills directory-submissions），不是实测排名——记录每个目录的实际引荐流量（Measured，自有分析），以便下次发布按数据重排波次。
7. 执行红线检查：绝不拉票或组织投票/互动互刷——不搞互赞群、不发“请点赞”私信或邮件、不向支持者下达协同时间指令；这是 RAMP M1 否决的执行面，一次违规即可让整个发布在关口被拦。例外：请受众对在线帖子给反馈是可以的。不要删除低热度帖子重试（违反多数社区规范且抹掉 Measured 基线）；不要在 registry 记录的禁发期承诺前发帖；绝不用激励换商店评价——仅在该平台政策明确允许时（G2 类）才可用激励，且按其公布条款。
8. 一次一个平台地执行并留回执：每次提交创建一条精确意图，含平台/账号、包哈希、manifest 哈希、计划时间和负责人；取得该操作专属授权后执行，再把提供方/URL 结果捕获为该动作的回执。partial、failed、缺失或未知的回执保持未决。只有回执证据存在后，才可把对应的带日期状态事实通过授权 operation: propose 请求提交到 memory/events/launches.ndjson；提案不等于回执。不要计算 RAMP 结果或发布 go/no-go。
9. 交付后询问“是否保存结果供未来会话使用？”确认后保存到 memory/launch/community-launch-runner/YYYY-MM-DD-<launch-slug>-submissions.md；提交事实（平台、时间戳、状态、URL）通过授权 operation: propose 请求提交到 registry-events.py 写入 memory/events/launches.ndjson，由 launch-registry 提升——绝不直接写 dossier。未经询问不要写 memory。

适用边界 · 注意事项

• 不适用于付费放大（用 content-amplifier）、创作者渠道（用 campaign-planner）、发布遥测读数（用 launch-monitor），也不适用于发布窗口之外的持续社区存在或预热养号（用 participation-warmup-planner）。
• 缺少已接受发布状态或 manifest 哈希不匹配（Unknown/NEEDS_INPUT）时不要提交。
• 不要计算 RAMP 结果或发布 go/no-go——那是 launch-readiness-auditor 的关口职责。