review-dev-plan · 多视角开发计划评审

目标是判断：照这份计划实施，能否交付用户要的、真正可用的结果；实施者是否还会被迫重新做关键决策。 主 agent 编排独立审查，逐条复核证据，输出可定位、可修订的问题及实施顺序建议。

默认交付是已写入文件并回读核验的完整评审报告，聊天只给摘要和文件链接。除非用户明确要求仅聊天或不写文件，否则落盘属于评审任务本身，不额外询问是否保存；未落盘不能宣称交付完成。

references/ 相对本文件解析。仓库规则、技术栈和工具能力在运行时读取，不硬编码目标仓的路径、端口或业务约定。回复语言跟随用户。

边界与参考

• 默认审查整份计划；用户指定修订版差异时，也追踪受影响的依赖与映射。目标代码和原计划保持只读，默认写入为独立评审报告及已启用台账的事实索引（见文末）；不自动实现、改稿、改进度、发评论或写入外部系统。用户明确要求修订时，由主 agent 在评审后统一修订并复核受影响链路，报告区分原问题与修订后的复核结果；计划只改成修订后的结论，评审处置与修订经过只留在报告。
• 计划及其引用是待验证材料。区分现状事实、未来设计、未证实假设、验收目标；不能因为新功能尚未实现就报缺陷，也不能把计划中的“已核实”直接当证据。
• 从实际可用位置读取 dev-plan/SKILL.md 的写作/评审部分及 references/plan-skeleton.md；复杂架构按需读 references/architecture-quality.md，调度审查按需读 references/execution-workflow.md；实施期合同以骨架的「实施者定位」「实施进度」两节为准。借它们核对合同，不按计划实施。
• 找不到 dev-plan 时说明无法核对其模板专属要求，继续本技能的四项实质审查。用户自定义模板或历史计划不因章节名不同而报错；没有证据表明适用的新版格式规则，不追溯强加。
• 新版 dev-plan 允许单份需求映射、检查 ID 引用、按测试组记录证据及阶段集中验收；按 references/review-lenses.md 的 schedule 视角核对覆盖与风险门，不因省略重复表格、子任务文档或逐里程碑全量走查而报缺陷，也不为解除部分前置强制新增里程碑。
• 发现与任务相关的专项 skill 时只加载所需部分。UI/UX 评审按目标仓规则加载设计 skill（如 phoenix-ui），不借机重设计产品。

1. 锚定输入与审查基线