plan-it

规划

从原因出发制定计划：这项变更为何对用户重要，如何融入现有系统，以及交付什么可验证的切片。除非精确代码、文件名、编辑顺序和命名属于契约，否则将这些留给实现阶段决定。

边界

• 仅检查解决规划决策所需的说明、代码、测试和配置。复用现有上下文，不要为了形式而反复重读。
• 仅做规划并不代表获准修改产品或创建持久化产物。除非获准使用其他位置，否则将计划保留在对话中。
• 如果有帮助或有要求，请使用运行环境提供的规划支持。对于规模小、目标明确且风险低的变更，用简短的对话计划即可。
• 如果用户只询问可行性，说明方案、影响、风险和是否可行，然后停止。

1. 明确 Why

首先说明变更面向哪些人、要为他们解决什么问题，以及从他们的角度看，怎样才算成功。Why 是验收标准的来源，也是判断范围是否合适的依据。

请求必须包含三项内容：期望的能力、验收标准和用户价值。只询问缺失的信息；不要重复询问用户已经说明的内容。如果用户只给出 How（“添加一列”“切换到 X”），询问其目的。

2. 决定 How

如果仓库有验证技能，请在其功能映射中查找请求提到的功能；其中的 Where it lives 部分是查找代码的起点，Driving it 部分则用于确定验收方式。结合现有系统选择方案：说明要扩展哪个现有模块、接口或模式，哪些内容保持不变，以及哪些权衡值得考虑。仅在选择确有影响时比较备选方案。保持抽象——不提供代码、伪代码或编辑步骤清单。

如果方案取决于尚未确认的事项——例如外部端点、GPU 路径、第三方权限或部署目标——请先实际验证，再确定计划：运行一次调用或操作，以确认其可用。在此处发现依赖受阻，只需追问；若在构建后才发现，就得付出构建成本。

3. 将 What 划分为切片

按顺序列出交付切片。每个切片包括：

• 结果——用户或调用方可以观察到的结果。
• 验收——如何在真实系统中证明该结果：使用的命令、请求或用户操作流程，以及通过时应观察到的结果。测试、类型检查或 lint 等检查可辅助验收，但不能取代验收。
• 边界——涉及的模块或契约，以及有意不涉及的内容。
• 价值——该切片推进 Why 的哪一部分。

不服务于 Why 的切片应直接删去，而不是延后到同一分支中。拆分工作，使每个切片都能独立提交、审查和回退；如果一个切片会横跨几个无关边界，就应拆开。安排切片顺序时，确保每个切片都建立在已验证的基础上。

4. 确定验证方式和权限

• 测试优先。 遵循用户的选择或项目政策；否则自行选择并说明。如果选择 TDD，行为变更切片的 /implement-plan 应遵循 /tdd。使用 测试判断 决定新增测试是否能扩大覆盖范围。
• 项目验证。 如果项目有验证技能，请注明其名称；否则说明此类应用将如何驱动验收，并建议用户运行 /create-verification-skill。
• 提交。 说明每个切片通过后是否自动提交，还是仅在用户要求时提交。
• 审批。 提出需要审批的新设计决策、破坏性操作，或对共享系统或生产系统产生的影响。只询问会阻碍制定可靠计划的问题。

输出

根据风险调整细节。小型变更只需几行，涵盖 Why、How 和一个切片。对于较大的变更：

## Why

## How

## What

## Validation and Authority

## Risks and Open Decisions

完成标准

计划说明了 Why、How，以及按顺序排列的各个切片；每个切片都有可观察的结果、针对真实系统的验收检查、边界，以及与 Why 的链接；已检查未观察到的依赖项是否可行，或将其列为风险；已记录测试优先的选择、验证方法和提交策略。在仅限规划的授权下，尚未进行任何实现。

获得批准后，使用 /implement-plan 继续。如果用户已经授权了明确且低风险的实现，简要计划无需再引入一轮审批；新的设计决策仍需获得批准。