从定位画布推导发布消息屋、PR-FAQ 与渠道角度包

当已有完成的定位画布，需要为产品发布生成消息屋、工作回溯式 PR-FAQ 叙事骨架和分渠道消息角度时使用。

适用场景

解决思路

1. 验证 L1 输入：要求有可用的定位画布，以及已接受的 Narrative 和 claims 投影；若缺少 canon，请求明确的探索性回退或停止，绝不把回退版发布消息屋当作规范或可发布内容。
2. 搭建屋顶：从画布的价值主题推导 tagline 和 one-liner；在呈现前用 skill-contract.md 中的 Output Voice 禁用词表检查两者，基于禁用填充词的 tagline 属于缺陷而非风格选择。
3. 树立支柱：写出三个价值支柱，每个都可追溯到画布的价值主题，并为每个 persona 提供证明点；将每个证明点标注为 Measured（自有分析/导出）、User-provided 或 `[needs source]`；绝不把未验证的数字当作事实，也绝不编造基准来填补空白。
4. 撰写 PR-FAQ 骨架：采用工作回溯风格，新闻稿用发布日时态（仿佛发布已经发生），用数字而非形容词，并通过空椅测试（指定的 ICP 读者是否会在意每一句话）；然后写五个外部 FAQ（买家异议、定价、对比）和五个内部 FAQ（团队宁愿跳过的难题）。
5. 裁剪分渠道角度包：为每个发布渠道给出角度、主打证明点和目标 persona——是角度，不是成品文案；当渠道有字符限制（商店列表）时，引用官方 App Store Connect / Play Console 文档并标注“verify current”；保持公告 ↔ 落地页 ↔ 优惠说同样的话（RAMP-`A` 消息匹配子项）。
6. 清扫 claims：只使用已为发布场景接受的 claims；未解决的措辞保留 `[needs source]`，将发布用途的依赖状态设为 blocked，并通过运行时将每一项作为授权的幂等提案提交。
7. 运行禁用词自检：对照 Output Voice 禁用词表扫描 tagline、one-liner、支柱和 PR-FAQ，重写每一处命中；当用数字替换形容词时，该数字必须是 Measured 或 User-provided——否则将该 claim 排除或标注 `[needs source]`。
8. 交付后，在写入 `memory/launch/message-house-builder/YYYY-MM-DD-<topic>.md` 前先询问；包含 canon/version/claims offset；通过 `registry-events.py` 将 claim 和发布事实作为单独的授权提案事件提交，绝不通过编辑 NDJSON 或投影来提交。

适用边界 · 注意事项

• 缺少定位画布时——应先路由到 positioning-mapper，而不是自行构建定位。
• 需要成品博客文章、页面、广告或邮件单元时——应使用 content-writer、ad-creative-builder 或 email-creative-builder。
• 需要裁定 claims 或组装新闻资料包与资产清单时——应使用 offer-claims-registry 或 launch-asset-packager。