| name | design-review |
| displayName | 技术方案评审 |
| description | 对现有技术方案进行正确性、完整性、风险和落地可行性评审,并指出关键问题与改进建议。适用于方案自评审或用户主动发起的设计评审。 |
| triggers | ["技术方案评审","设计评审","方案review","架构review"] |
| autoTrigger | true |
| version | 1.0.2 |
技术方案评审
技能目标
对已有技术方案、设计文档或架构草案进行结构化评审,优先识别关键风险、遗漏项和落地问题,输出可直接用于后续修订的评审结论。
评审重点
- 目标和范围是否清晰
- 主流程、异常流程、状态流转是否闭环;核心业务流程是否已用 mermaid 流程图或时序图表达清楚
- 数据结构、接口和依赖改动是否在「代码实施位置」或架构方案对应章节中说明完整
- 既有代码结构映射是否充分:是否写明参考的现有模块、类、目录、调用链和代码风格
- 代码落点是否可执行:是否列出新增/修改/删除文件、所属层级、放置原因和对应测试文件
- 默认「功能技术方案」是否保持轻量,只包含 4 个核心部分:功能概述与边界、核心业务流程、代码实施位置、测试与验收;只有用户明确要求架构设计方案时,才按 8 部分架构模板评审
- 架构设计方案中,一致性、幂等、回滚、监控、测试、发布和回退策略是否足够
- 澄清答案一致性:方案中标注
[用户确认] 的设计点,以及其他源自用户明确答案的设计决策,是否被完整、准确地体现?是否存在方案偷偷扩展、覆盖或变通用户明确答案的情况?(若发现此类偏离,应列为 Critical 问题)
阻断性缺失判定
以下缺失会直接影响编码阶段是否能保持现有风格和业务一致性,评审时必须至少列为 Important;若会导致无法判断实现位置或业务主流程,则列为 Critical:
- 缺少核心业务流程图,无法确认主流程闭环。
- 缺少异常流程或关键业务规则,编码需要自行猜测。
- 缺少既有代码结构映射,无法判断应复用或参考的现有实现。
- 缺少代码落点计划,无法明确新增/修改文件应放在哪里。
- 缺少测试落点或验收方式,无法验证方案是否实现。
输出规则
- Findings 优先,总结后置
- 若某类问题不存在,应明确写"无"
- 若未发现关键缺陷,应明确写出"未发现关键缺陷",并补充剩余风险或测试缺口
- 每条意见尽量落到具体设计点,避免泛泛而谈
评审输出模板
# 方案评审:{主题名}
## 1. 评审结论摘要
- 总体结论:
- 风险等级:
- 从评审角度是否具备进入实现阶段的前提(**在 `/start` 的 A2 中**:仅表示评审意见,**不是**编码授权;**禁止**据此自动写代码。获准实现须 `commands/start.md` 第三步用户确认,且若继续则须第四步选「继续编码」或另开 `/code`。)
## 2. Critical
- [问题标题]
- 影响范围:
- 问题说明:
- 建议修改方向:
- 优先级:
## 3. Important
- [问题标题]
- 影响范围:
- 问题说明:
- 建议修改方向:
- 优先级:
## 4. Nice to have
- [问题标题]
- 影响范围:
- 问题说明:
- 建议修改方向:
- 优先级:
## 5. 总体结论与后续建议
- 建议优先处理项:
- 可延后优化项:
- 仍需补充的信息:
评审后流转规则
在 /start A2 中:评审输出完成后的唯一下一步 = commands/start.md 第三步硬门禁。
「可开发」结论仅为评审意见,不构成编码授权。完整门禁协议见 commands/start.md 第三步。
子代理调用模式
本 skill 作为 design-reviewer 子代理的工作指令使用。当被子代理调用时:
- 在独立上下文中执行,不携带方案生成过程的思考链
- 评审输出通过结构化结果返回主 Agent,不直接与用户交互
- 主 Agent 负责将评审结论整合到第三步硬门禁展示中