启动产品、新增战略文档或调整方向/路线图时，创建或更新…

当需要为产品项目沉淀或维护 STRATEGY.md 时，用访谈式提问和受控更新生成/修订产品战略文档。

适用场景

解决思路

1. 日期文档时使用当前年份 2026。
2. 只写 `references/strategy-template.md` 指定的章节，维护 `STRATEGY.md` 中属于本 skill 的部分。
3. 保留 frontmatter keys 和本 skill 的各章节标题，因为下游 skills 会解析这些契约；若现有章节已有含义，则把新含义合并进去。
4. 先读取 `references/grounding.md`，获得完整来源清单、分歧问题措辞和 focus hint 的处理方式。
5. 构建 repo model：若存在则读 `STRATEGY.md`。
6. 从产品声明的意图与结构中理解产品是什么：README、`CONCEPTS.md`、`docs/`、类似 `PRODUCT.md` 的兄弟文档、代码围绕什么组织。
7. 将 repo model 的阅读范围限定在“这是什么、为谁服务”，不要剖析整个 repo。
8. 从最近 commits 或 PRs 了解当前注意力去向；注意力只用于 Tracks 问题和更新运行中的过时判断；若与声明意图冲突，向用户提问，不自行下结论。
9. 在第一个问题前，在聊天中展示 repo model：3-5 行说明你认为产品是什么、似乎服务谁、注意力去了哪里，每点注明来源，并邀请用户纠正。
10. 若 repo model 没有给出产品名称，在这里询问产品名称，因为模板 frontmatter 和标题需要它。
11. 若 repo 没有实质内容，用一句话说明，然后以未 grounding 的方式运行访谈。
12. 根据文件状态宣布下一阶段：无文件 -> Phase 1，输出 “Strategy doc not found - let's write it.”，若适用则先按 `references/grounding.md` 提供 legacy-sibling 选项；有文件 -> Phase 2，输出 “Found existing strategy - let's review and update.”。
13. 第一个问题前读取 `references/interview.md`。
14. 使用 `references/interview.md` 中的开场问题、pushback 规则、反模式示例、质量门槛、各 host 的 blocking-question 工具、两轮上限；不要凭记忆 improvisation。
15. 按顺序访谈：Purpose、Positioning、Users、Key metrics、Tracks、Stress test、Boundaries（总是写）、Milestones（可选）、Brand（可选）；文档本身按模板顺序，Boundaries 在 stress test 后询问。
16. 每次只问一个问题，并通过当前工具列表中已有的 host blocking question tool 提问。
17. 按能力匹配 blocking question tool；不要探测用户可见工具来发现它。
18. 只有在没有此类工具或真实问题调用出错时，才在可见聊天界面回退到编号选项。
19. 不要静默跳过问题。
20. 若调用时带参数，将其视为 focus hint：要重访的章节（`metrics`、`positioning`、`tracks`；旧名如 `approach` 或 `who it's for` 映射到当前章节）或范围提示；没有参数则开放式进行，由文件状态决定路径。
21. 所有章节捕获后，读取 `references/strategy-template.md` 并填写。
22. 在聊天中展示完整草稿，提供一轮编辑，然后写入 `STRATEGY.md`。
23. 对更新运行：先读取 `references/update-run.md`，必须在摘要、drift check 或任何问题之前。
24. 更新运行中用 3-5 行总结文件当前状态。
25. 将 repo model 显示可能 stale 的章节命名为 drift candidate，而不是最终结论。
26. 重访 focus hint 指定的章节；若无，则询问用户选择要重访的章节。
27. 允许用户选任意章节；先列出 drift candidates 作为建议，而不是唯一选项。
28. 保持其他所有章节内容不变；其位置按 `references/update-run.md` 中的 ownership test 决定。
29. 更新运行中的问题与 pushback 仍来自 `references/interview.md`，像首次运行一样应用。
30. 判断文件是否仅由本 skill 拥有：若是，每次写入保持 house format：重命名标题、按模板当前顺序排列章节、对缺失的必需章节发出提议；不要仅因文件原则上共享就视为多写入者。
31. 对任何其他形态（手写或来自其他工具）的文件：按含义阅读，按其自身形态和惯例编辑；不要重构成模板，不要添加未经邀请的 frontmatter 或标题。
32. 无论哪种形态，都不编辑：带作者批准标记的章节（如 `<!-- <tool>: author-approved 2026-07-10 -->`），以及用户不拥有的文档。
33. 对上述不可编辑情况，报告冲突，或写一个单独文件并链接到它。
34. 定向更新时，精确保留其他每个章节的内容。
35. 被更新章节的位置遵循同一 ownership test：仅本 skill 拥有的文件采用模板顺序；多写入者文件从不重排。
36. 编辑现有文件前必须读 `references/update-run.md`，它定义其余规则。
37. 战略文档是 anchor，不是计划：只写产品是什么与为什么；功能放 `ce-brainstorm`，排期和优先级放 issue tracker，实施计划放 `ce-plan`；不要让它们混入文档，也不要更新 tracker 或协调进行中的工作。
38. 用户作答；repo 只用于把问题问得更尖锐，永远不要用证据填充章节，也不要从 repo 推导战略。
39. 简短是特性：遇到扩展倾向要 push back，而不是增加章节。
40. 记录哪些指标重要以及它们在哪里，不记录当前读数。
41. 在 Phase 3 用一行说明文件位置，并说明 `ce-ideate`、`ce-brainstorm`、`ce-plan` 会在下次运行时把它作为 grounding 读取。
42. 若这里尚无下游 skill 运行过，建议下一步运行 `ce-ideate` 或 `ce-brainstorm`。
43. Done 标准：`STRATEGY.md` 位于 repo root，用户已看过将写入内容并完成编辑轮；对 house format，每个必需章节都由经得起 pushback 的答案填充（或明确 defer 到链接的 legacy doc），且文件匹配 `references/strategy-template.md`；对其他形态，done 是应用用户批准的最小编辑，且文档形态不变。
44. 若某章节两轮仍无法 sharpened，按用户给出的内容写入，并在聊天中标记为值得重访；这算完成运行，不是阻塞。

适用边界 · 注意事项

• 不要用于制定功能清单、排期、优先级或实施计划；这些交给 `ce-brainstorm`、issue tracker、`ce-plan`。
• 不要把 repo 证据当作战略答案来源来自动填充章节；不要从 repo 推导战略。
• 不要编辑用户不拥有的文档，或带作者批准标记的章节；遇到冲突应报告或另写链接文件。