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 - コメントを投稿