ce-strategy

产品战略

当前年份为 2026 年——为文档填写日期时使用这一年份。

ce-strategy 编写并维护 STRATEGY.md 中由它负责的部分——这是位于仓库根目录的项目文档，记录项目是什么、服务谁、如何取得成功，以及团队将资源投入到哪里。该文件由其他工具和人员共享；此技能只编写 references/strategy-template.md 中列出的章节。下游技能会在文件存在时读取它：ce-ideate、ce-brainstorm 和 ce-plan 用它判断哪些工作符合战略方向；ce-product-pulse 用它获取产品名称和关键指标；ce-dogfood 用它确定主要用户画像。Frontmatter 键和此技能的章节标题是这些技能解析内容时所依赖的约定——此技能编写的每个章节都要保留它们；若现有章节已包含某个含义，就将其合并进去（references/update-run.md）。

完成标准：STRATEGY.md 已存在于仓库根目录，用户已了解将要写入的内容，并有机会进行修改。对于采用此技能规定格式的文件，所有必需章节都已根据经受质疑后保留的回答填写（或明确延期至链接的旧版文档），且文件符合 references/strategy-template.md。对于其他格式的文件，完成意味着已应用用户批准的最小修改，同时保持文档原有结构不变。若某个章节经过两轮追问仍无法进一步明确，就按用户原话写入，并在聊天中指出值得日后重新审视——这仍算完成，而非受阻。

边界

• 锚点，而非计划。 战略说明产品是什么以及为什么。功能属于 ce-brainstorm，日程和优先级属于问题跟踪器，实现计划属于 ce-plan；不要让这些内容渗入文档，也不要更新跟踪器或协调正在进行的工作。
• 由用户作答；仓库只为问题提供依据。 利用证据提出更精准的问题，绝不能据此填写章节。不要从仓库推导战略。
• 简短本身就是优点。 应对内容扩展提出质疑，而不是增加章节。
• 记录哪些指标重要以及它们存放在哪里，而非记录它们今天的数值。
• 含义是约定；结构由文档创建者决定。 若文件完全由此技能拥有（references/update-run.md 说明了判定方法），每次写入都应维护为本技能的格式：重命名标题、按模板当前顺序排列章节，并提出补充缺失的必需章节。不要仅仅因为文件原则上是共享的，就将其视为多方协作文件。对于其他格式的文件，无论是手写还是由其他工具生成，都应按含义理解，并沿用其自身结构和风格进行编辑：不重构为模板格式，不擅自添加 frontmatter 或标题。无论哪种情况，以下两类内容绝不编辑：带有作者批准标记（例如 ``）的章节，以及用户不拥有的文档。对于这类情况，应说明冲突，或另写一个链接至该文档的独立文件。定向更新必须原样保留其他所有章节的内容。章节所在位置遵循相同的所有权判定：仅由此技能拥有的文件采用模板顺序；多方协作文件绝不重新排序。其余规则见 references/update-run.md；编辑现有文件前必须阅读该文档。

提问与路由

每次只通过当前工具列表中宿主提供的阻塞式提问工具提出一个问题。按能力匹配工具；切勿通过试探面向用户的工具来发现可用工具。只有在工具列表中没有此类工具，或实际调用提问工具出错时，才在可见聊天界面上提供编号选项。绝不能悄悄跳过提问。

调用此技能时附带的任何参数——无论出现在当前提示还是对话中，无论来自用户还是调用此技能的技能——都属于关注提示：可以是要重新审视的章节（metrics、positioning、tracks；旧名称如 approach 或 who it's for 对应当前章节），也可以是范围提示。若没有提示，就从开放式探索开始，根据文件状态决定后续路径。

阶段 0：了解背景并确定流程

无论运行环境读取什么，阶段 0 都会生成一份仓库模型，并决定接下来运行哪个阶段。references/grounding.md 是必须加载的文件：其中包含完整的来源清单、关于分歧问题的原文措辞，以及关注点提示。

仓库模型是你对该产品的工作理解。如果存在 STRATEGY.md，请阅读。根据产品明确表达的意图和结构来了解产品是什么——README、CONCEPTS.md、docs/、PRODUCT.md 等同级文档，以及代码的组织方式——并将这番了解限定在“这是什么产品，面向谁”，而不是全面分析整个仓库。通过近期提交或 PR 了解当前关注点。关注点只用于 Tracks 问题和更新运行中的过时判断；如果它与明确表达的意图不一致，这应作为问题交给用户，而不是得出结论。在提出第一个问题前，先在聊天中展示该模型：用 3 到 5 行说明你认为产品是什么、似乎服务于哪些用户，以及关注点落在哪里；每条都标明来源，并邀请用户纠正。如果模型未能提供产品名称，请在此处询问——模板的 frontmatter 和标题需要这个名称。没有实质内容的仓库也是正常情况：用一行说明这一点，然后在缺少背景的情况下进行访谈。

下一阶段由文件状态决定，并用一行宣布：没有文件 -> 阶段 1（“未找到策略文档——我们来写一份。”）；文件已存在 -> 阶段 2（“找到现有策略——我们来审阅并更新。”）。适用时，先按照 references/grounding.md 提供旧版同级文档选项。

阶段 1：首次访谈

在提出第一个问题前，阅读 references/interview.md——这是必须加载的文件。开场问题、反问规则、反模式示例、质量标准、各宿主对应的阻塞问题工具，以及最多两轮的限制都在其中；凭记忆临场发挥会导致被动转录，而非撰写策略文档。

按以下顺序进行访谈（文档本身遵循模板的顺序；边界是在压力测试之后询问的，因为其内容源自压力测试）：

1. 目标
2. 定位
3. 用户
4. 关键指标
5. Tracks
6. 压力测试
7. 边界（始终要写）
8. 里程碑（可选）
9. 品牌（可选）

记录完所有部分后，阅读 references/strategy-template.md 并填写模板，在聊天中展示完整草稿，提供一轮修改机会，然后写入 STRATEGY.md。

阶段 2：更新运行

先阅读 references/update-run.md——这是必须加载的文件，须在摘要、偏差检查或提出任何问题之前完成。该文件规定如何提出偏差候选项、复访哪个部分，以及哪些内容保持原样。更新运行需用 3 到 5 行概述文件的当前状态，并将仓库模型认为可能过时的部分列为候选项，而非定论。然后复访关注点提示指定的部分，或询问用户后由用户选择的部分。用户可以选择任意部分；先列出偏差候选项作为建议，而不是将它们作为唯一选项。其他所有部分的内容都保持原样，其归属遵循 references/update-run.md 中的归属判定。问题和反问仍来自 references/interview.md，并按照首次运行的方式应用。

阶段 3：下游交接

用一行说明文件所在位置，并说明 ce-ideate、ce-brainstorm 和 ce-plan 会在下次运行时将其作为背景信息。如果此处还未运行任何下游技能，可建议下一步运行 ce-ideate 或 ce-brainstorm。