design-review

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 负责将评审结论整合到第三步硬门禁展示中