用途：根据仓库证据生成可执行的实施计划，或强化已有计划。规划本身不产生实现改动；若用户要求规划并实现，则在完成计划后按宿主当前模式与授权继续。
主要模式：创建（无计划时，基于仓库写计划）；审查（已有计划时，核实关键论断并解决具体缺口）；访谈（用户要求被追问时，交互式探索决策）；拆分（多个可独立交付的成果需要带原生依赖链接的工单）。架构契约用 codebase-architecture，代码发现用 tidy。
工作流：确定目标成果与权威计划路径，优先使用宿主的计划文件；持久交接默认放在 docs/plans/<slug>.md，并指明哪份为权威。检查约束本次改动的模块、测试与决策，能由仓库回答的问题自行解决，仅在未决选择实质影响范围、行为或难以回退的操作时提问。选择能触达真实边界的最小垂直切片，说明其扩展的现有代码或平台能力；新增依赖或抽象需有现有机制无法满足的当前需求。按计划契约撰写，并用评分标准复核关键论断，直接修复有证据的缺口。
计划契约按需包含：成果（触发问题、预期行为、验收标准）、方法（所选切片、受影响文件或接口、迁移顺序）、决策（问题、选择、决策者与时间、各选项的实测证据、何种情况会改变结论、未验证假设）、边界、验证（每条验收标准对应的命令、测试场景或观察，含预期失败行为）、文档（本次改动会使其失效的当前文档，同 PR 更新）、恢复（迁移与不可逆写入的回滚或恢复）。
交接需自包含，用决策替代“如所讨论”，把用户更正保留在文件中。工单按可交付成果拆分，而非按数据库/后端/前端分层。
限制与注意：~/.claude/plans/ 中的计划对其他检出或 CI 不可用，持久交接需项目产物；仅写“运行测试”不足以确立行为变化，需指明验收场景与预期结果；发布切片若无原生阻塞关系，执行队列无法感知依赖；为旧版本写的计划可能引用已移动文件，需对照当前检出核实关键路径与接口。仅维护时，evals/evals.json 含本技能的回归场景，用户任务中不加载。评分可选，使用时标记未验证论断并说明残余缺口。