acceptance-criteria-verification

验收标准验证

概述

系统地验证每项验收标准，并发布结构化报告。

核心原则： 验证每项标准。记录每次验证。

开始时宣告：“我正在使用验收标准验证流程来验证实现。”

验证流程

第 1 步：提取标准

阅读议题并提取所有验收标准：

# Get issue body
gh issue view [ISSUE_NUMBER] --json body -q '.body'

解析出各项标准（在验收标准部分中查找 - [ ] 或 - [x] 模式）。

第 2 步：规划验证

针对每项标准，确定：

标准	测试类型	验证方式
[标准 1]	单元测试	运行指定测试
[标准 2]	集成测试	调用 API 并检查响应
[标准 3]	E2E	浏览器自动化
[标准 4]	手动	目视检查

第 3 步：执行验证

针对每项标准，运行相应的验证：

单元测试/集成测试

# Run specific tests
pnpm test --grep "[test pattern]"

# Or run test file
pnpm test path/to/specific.test.ts

E2E 测试

# If using Playwright
npx playwright test [test file]

# If using browser automation MCP
# Use mcp__playwright or mcp__puppeteer

手动验证

对于需要目视或交互验证的标准：

1. 启动应用程序
2. 导航到相关区域
3. 执行操作
4. 如有相关内容，截取屏幕截图
5. 记录结果

第 4 步：记录结果

针对每项标准，记录：

Criterion: [Text from issue]
Status: PASS | FAIL | PARTIAL | SKIP
Evidence: [Test output, screenshot, observation]
Notes: [Any relevant details]

第 5 步：发布验证报告

在议题中发布结构化评论：

gh issue comment [ISSUE_NUMBER] --body "## Verification Report

**Run**: $(date -u +%Y-%m-%dT%H:%M:%SZ)
**By**: agent
**Commit**: $(git rev-parse --short HEAD)
**Branch**: $(git branch --show-current)

### Results

| # | Criterion | Status | Notes |
|---|-----------|--------|-------|
| 1 | [Criterion text] | PASS | [Notes] |
| 2 | [Criterion text] | FAIL | [What failed] |
| 3 | [Criterion text] | PARTIAL | [What works, what doesn't] |

### Summary

| Status | Count |
|--------|-------|
| PASS | X |
| FAIL | X |
| PARTIAL | X |
| SKIP | X |
| **Total** | **X** |

### Test Output

<details>
<summary>Test Results</summary>

\`\`\`
[test output here]
\`\`\`

</details>

### Next Steps

- [ ] [Action items for failures/partials]
"

第 6 步：更新议题复选框

针对每项通过的标准，在议题正文中将其勾选：

# Get current body
BODY=$(gh issue view [ISSUE_NUMBER] --json body -q '.body')

# Update checkboxes for passing criteria
# (Implementation depends on body format)

# Update issue
gh issue edit [ISSUE_NUMBER] --body "$NEW_BODY"

第 7 步：更新项目字段

# Update project fields using project-status-sync skill

# Verification status
# - All PASS → Passing
# - Any FAIL → Failing
# - Mix of PASS/PARTIAL → Partial

# Criteria Met count
# - Count of PASS criteria

# Last Verified
# - Current date

# Verified By
# - "agent"

状态定义

状态	含义	操作
PASS	标准已完全满足，且已验证可正常工作	在议题中勾选
FAIL	未满足标准，需要修复	记录失败项，返回开发阶段
PARTIAL	可以工作，但存在问题，需要改进	记录问题，可能需要修复
SKIP	无法验证（受阻、不适用等）	记录原因

E2E 验证最佳实践

使用浏览器自动化时：

1. 从全新环境开始 - 每次验证都使用新的浏览器会话
2. 收集证据 - 在关键环节截取屏幕截图
3. 检查可见状态 - 不仅检查 DOM，还要检查实际显示效果
4. 测试错误情况 - 不要只测试正常流程
5. 清理 - 验证后关闭会话

// Example verification flow (pseudo-code)
await page.goto(appUrl);
await page.click('[data-testid="new-chat"]');
await page.waitForSelector('[data-testid="chat-input"]');
await page.screenshot({ path: 'new-chat-verification.png' });
// Verify expected state
const title = await page.title();
expect(title).toContain('New Chat');

处理失败

当标准未通过时：

1. 具体记录失败项
2. 如果不明显，提供复现步骤
3. 收集错误消息或屏幕截图
4. 返回开发阶段进行修复
5. 修复后重新运行验证

不要：

• 失败时将状态标记为 PASS
• 因为“应该能正常工作”而跳过验证
• 忽略间歇性失败

验证清单

完成验证前：

• 已评估所有验收标准
• 每项标准都有明确的 PASS/FAIL/PARTIAL/SKIP 状态
• 已为每项标准收集证据（测试输出、屏幕截图）
• 已在议题中发布验证报告
• 已为通过的标准更新议题复选框
• 已更新项目字段
• 如果存在失败，已记录后续步骤

验证后

根据结果采取相应操作：

总体结果	后续操作
全部 PASS	进入代码审查
存在 FAIL	返回开发阶段，修复并重新验证
仅有 PARTIAL	与用户讨论：是否可以接受，还是需要修复？

集成

此技能由以下内容调用：

• issue-driven-development - 第 8 步

此技能调用：

• project-status-sync - 更新验证字段
• issue-lifecycle - 发布评论