在需要为品类变革构建战略叙事弧时…

当你要在信息屋（message house）之前先搭建一条持久的战略变革叙事弧——命名旧世界、不可否认的转变、新规则下的赢家与输家、应许之地及其证据——时使用。

适用场景

解决思路

1. 确认上游材料存在：定位真相集（positioning truth set）与信念地图（belief map）。若任一缺失，以 NEEDS_INPUT 停止并路由到 positioning-truth-tracer 或 audience-belief-mapper，不要在此臆造定位或信念；同时读取 memory/narrative-registry/ 中已有 canon，确保新弧是延伸而非矛盾。
2. 命名旧世界：描述滩头受众所处的现状，以及支撑它但如今已动摇的假设。痛点与「旧规则」要从信念地图的 push/anxiety 力量中提取，而非来自功能差距清单；旧世界必须是所列替代方案（含现状/电子表格/什么都不做）真正占据的世界。
3. 陈述不可否认的转变：指出那个让旧世界难以为继的单一变化，措辞要让怀疑者无法轻易否定。用带日期的证据支撑：将市场变化数据标注为 Measured（自有分析）/ User-provided / Estimated，并将任何 tavily.py / gdelt.py 信号标注为 proxy，绝不标为 Measured。若转变仅依赖厂商自家产品发布，则标记为弱节拍。
4. 画出赢家与输家：说明谁在新规则下胜出、谁被淘汰。此处把信念地图中的 pull/habit 力量转化为利害关系。聚焦市场结构，而非针对竞争对手的打击；对具名对手的比较性主张留到第 6 步。
5. 描绘应许之地：把转变给滩头受众带来的未来，表达为该细分人群在意的价值（取自真相集的价值主题），而非功能清单。将愿景性表述与声称的事实分开，把愿景标注为 vision——把未标注的未来当作现在时事实来断言，是下游 T1 级缺陷。
6. 锚定证据节拍：为让应许之地可信，列出证据——证明故事、基准、演示或案例。每条标注 Measured / User-provided；若不可验证或属比较性，则标为 [needs source] 并通过向 registry-events.py 提交经授权的 operation: propose 请求写入 memory/events/claims.ndjson。本技能只决定叙事弧需要哪些证据，绝不裁定主张是否真实——那是 claims ledger 的职责。
7. 组装并自检叙事弧：按顺序排列五个节拍，把信念地图中的异议重构放在它们所回应的节拍旁，并列出未决主张。做空椅测试（具名滩头读者是否会在意每个节拍？），确认叙事弧是一个关于变化的故事，而非能力清单。为每个数据点标注 Measured / User-provided / Estimated / proxy。
8. 交付后询问「是否保存结果以供未来会话使用？」确认后保存到 memory/narrative/strategic-narrative-designer/YYYY-MM-DD-<topic>.md。每个 [needs source] 证据节拍只通过向 registry-events.py 提交经授权的 operation: propose 请求写入 memory/events/claims.ndjson；稳定的 canon 级叙事弧只通过同样方式写入 memory/events/narrative.ndjson——绝不直接写 memory/narrative-registry/ 的 canon 文件，只有 narrative-registry 才能提升它们。未经询问不要写 memory。

适用边界 · 注意事项

• 不要用于撰写持久信息屋本身（标语、支柱、样板文案、canon 记录）——应使用 message-system-architect。
• 不要用于销售/融资路演叙事——应使用 pitch-narrative-builder。
• 不要用于裁定或证实任何产品或比较性主张——应使用 offer-claims-registry；本技能只标记 [needs source] 并提交候选。