名称: 验证工作流 描述: 验证AI开发者工作流步骤输出和合同。在继续之前验证工作流步骤完整性时使用。 参数提示: <步骤类型> [规范路径] 允许工具: Read, Glob, Grep, Bash
验证工作流
验证AI开发者工作流步骤输出并确保合同合规。
参数
$ARGUMENTS:<步骤类型> [规范路径]步骤类型: 其中之一plan,build,review,fix规范路径: 规范文件的可选路径（如果未提供则自动检测）
步骤合同
| 步骤 | 输出类型 | 关键要求 |
|---|---|---|
plan |
规范文件 | 摘要、需求、标准、方法 |
build |
代码更改 | 提交带有前缀、测试通过 |
review |
报告 | PASS/FAIL状态、严重性评级问题 |
fix |
解决方案 | 问题已解决、无新问题 |
指令
步骤 1: 识别步骤类型
从参数解析步骤类型：
有效类型: plan, build, review, fix
步骤 2: 加载步骤合同
计划合同:
- [ ] 规范文件存在于
specs/*.md - [ ] 包含摘要部分
- [ ] 包含需求列表
- [ ] 包含验收标准
- [ ] 包含技术方法
- [ ] 范围有限且可实现
构建合同:
- [ ] 文件已修改或创建
- [ ] 提交存在且带有
build:前缀 - [ ] 无构建/链接错误
- [ ] 测试通过（如果存在）
- [ ] 所有规范需求已解决
审查合同:
- [ ] 报告生成，具有结构化格式
- [ ] STATUS 明确为 PASS 或 FAIL
- [ ] 问题具有严重性级别 (CRITICAL/HIGH/MEDIUM/LOW)
- [ ] 问题描述可操作
- [ ] 所有代码根据规范审查
修复合同:
- [ ] 所有标记问题已解决
- [ ] 提交存在且带有
fix:前缀 - [ ] 无新问题引入
- [ ] 验证确认解决
步骤 3: 验证输出
对于计划步骤:
# 查找最新规范文件
ls -t specs/*.md | head -1
# 检查必要部分
grep -c "## Summary\\|## Requirements\\|## Acceptance\\|## Technical" specs/latest.md
对于构建步骤:
# 检查构建提交
git log --oneline -5 | grep "^[a-f0-9]* build:"
# 检查构建状态
npm run build 2>&1 | tail -5
# 或: dotnet build 2>&1 | tail -5
# 检查测试
npm test 2>&1 | tail -10
# 或: dotnet test 2>&1 | tail -10
对于审查步骤:
# 检查审查报告
ls -t .claude/temp/*review*.md 2>/dev/null | head -1
# 验证 PASS/FAIL 状态
grep -E "STATUS:|Result:" review_report.md
对于修复步骤:
# 检查修复提交
git log --oneline -5 | grep "^[a-f0-9]* fix:"
# 验证无新问题
# (重新运行审查步骤)
步骤 4: 检查成功标准
对于合同中的每个标准：
- 执行验证命令/检查
- 记录通过/失败状态
- 捕获证据（文件路径、命令输出等）
步骤 5: 报告结果
生成验证报告。
输出
## 工作流验证报告
### 已验证步骤
**步骤:** {plan|build|review|fix}
**规范路径:** {如果适用，路径}
**时间戳:** {ISO-8601}
### 合同检查
| 要求 | 状态 | 证据 |
| --- | --- | --- |
| {要求} | ✅/❌ | {详情} |
| {要求} | ✅/❌ | {详情} |
| {要求} | ✅/❌ | {详情} |
### 输出验证
#### {输出名称}
- **路径:** {路径}
- **存在:** ✅/❌
- **格式有效:** ✅/❌
- **问题:** {如果有}
### 成功标准
| 标准 | 满足 | 证据 |
| --- | --- | --- |
| {标准} | ✅/❌ | {证据} |
| {标准} | ✅/❌ | {证据} |
### 整体状态
**结果:** VALID | INVALID
**摘要:** {验证结果的简要摘要}
### 发现的问题
1. **{严重性}:** {描述}
- **位置:** {位置}
- **预期:** {应该是什么}
- **实际:** {实际找到的}
- **建议:** {如何修复}
### 下一步
- {如果无效，推荐操作}
- {如果有效，继续下一步}
验证快速参考
计划验证命令
# 检查规范是否存在
test -f specs/*.md && echo "规范存在"
# 检查部分
for section in "摘要" "需求" "验收" "技术"; do
grep -q "## $section" specs/*.md && echo "$section: OK"
done
构建验证命令
# 检查提交
git log --oneline -10 | grep "build:"
# 检查测试
npm test --if-present || echo "无npm测试"
dotnet test 2>/dev/null || echo "无dotnet测试"
审查验证命令
# 检查报告格式
grep -E "^STATUS:|^Result:" review_output.md
# 检查严重性级别
grep -cE "CRITICAL|HIGH|MEDIUM|LOW" review_output.md
反模式
| 避免 | 为什么 | 替代 |
|---|---|---|
| 跳过验证 | 继续进行不完整工作 | 总是在下一步之前验证 |
| 部分检查 | 遗漏关键问题 | 完成所有合同检查 |
| 验证期间自动修复 | 范围蔓延 | 仅验证，单独修复 |
| 忽略警告 | 技术债务 | 处理所有严重性级别 |
交叉引用
- @composable-steps.md - 步骤合同
- @adw-framework.md - ADW 架构
workflow-validator代理 - 自动化验证composable-step-design技能 - 步骤设计模式