planning

规划

制定可执行的计划，或完善现有计划。仅规划不会产生实现方面的修改。当用户要求规划并实现时，完成计划后，继续按照宿主当前的模式和授权执行。

• 创建： 尚无计划；基于代码仓库确定方案并编写计划。
• 审查： 已有计划；核实其中影响重大的主张，并在文件中弥补具体缺漏。
• 访谈： 用户要求深入提问或接受访谈；通过互动探讨决策。
• 拆分： 有多个可独立交付的成果需要拆分成工单，并建立原生依赖链接。

架构契约使用 codebase-architecture；代码问题发现使用 tidy。

参考资料

文件	阅读时机
references/decision-briefs.md	向用户提出影响重大的决策：衡量选项、预览、记录答案
references/interrogation-protocol.md	决定该针对未决选择提出什么问题，或用户要求进行访谈
references/doc-grounding.md	ADR、规范或库文档会约束方案时
references/handoff-plans.md	将由其他会话或人员执行计划时
references/plan-quality-rubric.md	审查完整性、可行性、范围、可测试性、风险和假设
references/questioning-framework.md	审查发现缺漏，需要向用户提出有针对性的问题时
references/claim-verification.md	计划中的主张可通过代码或文档核查时
references/splitting.md	将工作拆分为可执行工单时

工作流

1. 确定用户要求的成果和权威计划路径。有宿主计划文件时，使用该文件。持久交接计划放在项目路径下，默认路径为 docs/plans/<slug>.md；注明哪份副本是权威版本。
2. 检查会约束此变更的模块、测试和决策。自行解决代码仓库能回答的问题。只有未决选择会实质性改变范围、行为或难以撤销的操作时才提问。常规假设写入草稿即可。提问前，先衡量各选项并说明什么因素会改变你的建议；如果关键因素只有用户知道，就直接询问该因素（references/decision-briefs.md）。
3. 选择能触及真实边界的最小纵向切片。指出要扩展的现有代码或平台能力。只有在现有机制无法满足当前需求时，才引入新依赖或抽象。
4. 按以下契约编写计划。依据评审标准核查一次影响重大的主张；有证据表明存在缺漏时，直接修正。交接计划还须通过 references/handoff-plans.md 中的陌生人测试。访谈模式可探讨相互竞争的方案，但没有最低提问数量要求。
5. 返回计划路径、未决决策和验证限制。宿主模式要求时，使用其审批机制。不要为了计划本身的审查再提出第二个审批问题。

计划约定

仅包含本次变更需要的部分：

• 结果： 触发问题、预期行为和验收标准。来自客户端或会议的需求须注明来源（时间戳、文档版本、截图），并标记为已决定、提议或推断。
• 方案： 选定的变更范围、受影响的文件或接口，以及适用时的迁移顺序。
• 决策： 决策日志：问题、选择、决策人和时间、各选项的测量证据，以及可能导致决策改变的因素；尚未核实的假设。
• 边界： 仅列出那些相邻变更可能被误认为属于本次范围的排除项。
• 验证： 针对每项重要验收标准，提供相应命令、测试场景或观察结果，并说明预期的失败行为。
• 文档： 本次变更会使哪些现有文档（即仓库标记为需保持准确的文档，例如文档索引中的“Current”条目）失效；并在同一个 PR 中更新这些文档。
• 恢复： 说明迁移和不可逆写入的回滚或恢复方式。

交接内容必须完整、独立。将“如之前所讨论”替换为具体决策。在文件中保留用户更正，而不只是留在聊天记录里。按可交付的结果拆分工单，而不是按数据库、后端和前端分层拆分。

完成评审

根据代码、任务或运行约束解决缺漏。不要添加推测性要求来提高自评。除非有人要求，否则评分可选；如需评分，请标明未经核实的说法，并说明剩余差距，不要反复修改直到每项都达到 5/5。

仅在进行实质性修改或获得新证据后重复评审。若用户尚未回答某项决策问题，请在受影响的步骤中记录，并继续处理相互独立的工作。如果用户要求跳过问题，请依据现有证据起草，并注明假设。

注意事项

• ~/.claude/plans/ 中的计划无法被其他检出版本或 CI 获取。持久交接内容需要作为项目文件保存。
• 只写“运行测试”不足以证明行为已变更。请明确验收场景和预期结果。
• 发布切片时，如果没有原生的阻塞关系，执行队列就无法获知依赖关系。
• 对转录或文档进行摘要或部分检索不等于完整阅读；请记录已完整阅读的来源，不要把部分覆盖报告为完整覆盖。
• 看似真实的占位内容（演示登录信息、虚假密钥、猜测的域名或角色）会被当作已确定内容并随之发布。请将每项缺口标记为缺失，并指出由谁提供；未说明的截止日期或预算应标为“未知”，而不是零或不限。
• “完成”可能指测试通过、已合并、已上线并验证，或已获请求方认可；每项验证标准都应说明它能确认哪一种状态。
• 为先前修订版本编写的计划可能包含已移动的文件。请根据当前检出版本核实重要路径和接口。

仅用于维护：evals/evals.json 包含针对本技能变更的回归场景；用户任务期间不会加载此文件。