从既有叙事正典推导融资/销售路演幻灯叙事（问题→拐点→产品英…

当需要把公司叙事正典转成销售 pitch 或融资 deck 的逐页叙事节拍大纲，并让每条证据节拍绑定到已批准 claim ID 时使用。

适用场景

解决思路

1. 确认正典存在并明确受众：读取 memory/narrative-registry/canon.md；若没有正典，则以 NEEDS_INPUT 停止并转交 message-system-architect，不要在此即兴编造公司叙事；确认目标是销售 pitch、融资 deck 还是两者，因为同一叙事弧在不同受众下证据侧重与诉求不同。
2. 从正典铺出五个节拍：problem（滩头客户感受到的痛点，取自正典的定位陈述）、the shift（让旧方式过时的不可否认的变化，取自战略叙事弧）、product-as-hero（产品在新格局中如何取胜——讲支柱而非功能堆砌）、proof（为什么承诺的应许之地是真的——牵引力、案例、基准）、the ask（受众下一步该做什么）；每个节拍都是对正典的复述，若某节拍需要正典未承载的 claim，应回头打磨正典而非在此发明。
3. 把节拍映射到幻灯片：一个叙事节拍对应一页（一个节拍可跨两页，但绝不把两个节拍压进一页）；对每页证据幻灯片，指明它取自 story-bank-builder 故事库的具体证据单元及其所依赖的 claim ID；保持公告↔deck↔offer 与正典其余部分说法一致（即 L 的 message-match 子项）。
4. 把每条证据节拍绑定到 ledger：每个证据（数据、案例结果、对比、logo）都必须追溯到 memory/claims/claims-ledger.md 中已批准的 claim；未获批准的一律标 [needs source]，并通过向 registry-events.py 发出经授权的 operation: propose 请求写入 memory/events/claims.ndjson，交由 offer-claims-registry 处理——本技能只决定证据落在叙事弧的哪里，绝不裁定其是否已证实；每个指标标注 Measured / User-provided / Estimated 并附 as-of 日期，绝不把 Estimated 的牵引力数字当作 Measured 呈现。
5. 裁剪受众专属诉求：融资场景给出融资规模、资金用途框架以及本轮买到的里程碑（每个数字都要标注）；销售场景给出具体的下一步（试点、试用、采购路径）；若同时面向两类受众，产出两个诉求变体加一个共享主体，不要分叉叙事弧。
6. 执行正典一致性与违禁词检查：核对没有任何节拍与正典的定位陈述、支柱或已批准 claim 措辞相矛盾（矛盾属于 L1 message-match 缺陷，标记并停止）；用 skill-contract.md 中的 Output Voice 违禁词表扫描标题文案并改写所有命中项，用数字替换形容词时该数字必须是 Measured 或 User-provided；随后对节拍行、标题和诉求跑 slop self-check，在交付大纲前清除 AI 腔措辞。
7. 组装大纲：五节拍叙事弧、带 claim ID 的幻灯节拍映射、分受众诉求、[needs source] 证据清单；为每个数据点标注 Measured / User-provided / Estimated，然后交接。
8. 交付后询问是否保存结果；确认后按 Skill Contract 的 Save Results Template 写入 memory/narrative/pitch-narrative-builder/YYYY-MM-DD-<topic>.md；每个 [needs source] 证据只通过向 registry-events.py 发出经授权的 operation: propose 请求写入 memory/events/claims.ndjson，起草中浮现的正典级措辞只写入 memory/events/narrative.ndjson，memory/narrative-registry/ 正典文件仅由 narrative-registry 写入；未经询问不要写 memory。

适用边界 · 注意事项

• 没有现成正典时（应先转交 message-system-architect，不要在此即兴编造公司叙事）
• 需要撰写发布窗口期的 battle card 或销售话术（应使用 sales-enablement-kit）
• 需要设计成品幻灯视觉、撰写持久消息层级或战略叙事弧本身、构建故事库，或裁定 claim 是否成立（分别超出范围或应转交对应技能）