name: review-workflow-design description: 设计基于规格的审核工作流，带有视觉证明和问题分类。用于设置审核流程、验证规格符合性，或实施基于截图的视觉验证。 allowed-tools: Read, Grep
审核工作流设计技能
设计审核工作流，以视觉证明验证实现是否符合规格。
何时使用
- 设置功能审核流程
- 创建价值证明工作流
- 设计基于规格的验证
- 实施自动解决循环
核心概念
审核回答：“我们构建的是我们要求的吗？”
这与测试不同，测试回答：“它工作吗？”
设计工作流
步骤 1: 定义规格位置模式
确定规格存储位置：
specs/
├── feature-{name}.md
├── bug-{name}.md
└── chore-{name}.md
或：
specs/issue-{number}-{type}.md
步骤 2: 设计截图捕获点
识别需要视觉证明的关键路径：
- 初始状态：交互前
- 关键操作：重要用户操作后
- 最终状态：功能结束结果
示例：
1. 截图仪表板（初始状态）
2. 点击“导出”按钮
3. 截图导出模态
4. 完成导出
5. 截图成功消息
步骤 3: 定义严重性分类
配置问题严重性级别：
| 严重性 | 标准 | 操作 |
|---|---|---|
| blocker | 阻止发布，损害用户体验 | 自动解决 |
| tech_debt | 质量问题，但工作 | 记录 |
| skippable | 优化，偏好 | 忽略 |
步骤 4: 设置解决工作流
设计自动解决循环：
审核
├── 发现问题？
│ ├── 有阻塞问题？ → /patch → /implement → 重新审核
│ └── 无阻塞问题 → 成功
└── 无问题 → 成功
最多 3 次重试尝试
步骤 5: 配置证明存储
截图存储选项：
- 本地：
agents/{adw_id}/review_img/ - 云：R2、S3 或类似（公开 URL）
- Git：与审核工件一起提交
审核命令结构
# 审核实现是否符合规格
## 变量
spec_file: $1
## 指令
1. **阅读规格**
- 理解需求
- 记录成功标准
2. **分析变更**
- git diff origin/main
- 与规格对比
3. **捕获截图**
- 关键功能 1-5 张截图
- 编号：01_name.png、02_name.png
4. **分类问题**
- blocker：发布前必须修复
- tech_debt：记录后续处理
- skippable：可忽略
## 输出格式
{
"success": boolean,
"review_summary": "string",
"review_issues": [...]
}
问题结构
{
"issue_description": "问题描述",
"issue_resolution": "如何修复",
"issue_severity": "blocker| tech_debt |skippable"
}
解决循环模式
for attempt in range(1, MAX_ATTEMPTS + 1):
review_result = run_review()
if review_result.success:
break # 无阻塞问题
blockers = filter(issues, severity="blocker")
for blocker in blockers:
create_patch(blocker)
implement_patch()
# 循环继续重新审核
与 SDLC 集成
/plan → 我们在构建什么？
/build → 实现它
/test → 它工作吗？
/review → 它是我们要求的吗？ ← 此技能
/patch → 修复阻塞问题
/document → 它如何工作？
最佳实践
- 截图是证明：向利益相关者展示交付内容
- 规格是真理：基于规格审核，而非假设
- 严重性重要：只有阻塞问题需要立即解决
- 重试限制：防止无限循环（通常 3 次尝试）
- 记录技术债务：不要丢失信息
内存参考
- @review-vs-test.md - 此技能实现的区别
- @issue-severity-classification.md - 如何分类问题
- @one-agent-one-purpose.md - 审核作为聚焦目的
版本历史
- v1.0.0 (2025-12-26)：初始发布
最后更新
日期： 2025-12-26 模型： claude-opus-4-5-20251101