フェーズ 5: 検証

目的

実装されたコードが期待通りに動作することを、証拠に基づいて証明する。テストの実行結果を確認し、カバレッジを測定し、品質基準を満たしていることを宣言する前に検証を完了する。

開始条件

• 実装差分と docs/workflow/implementation-handoff.md が揃っている
• 受入条件を追跡でき、計画の検証コマンドを実行できる

入力成果物

• 実装差分と追加・更新されたテスト
• docs/workflow/requirements.md
• docs/workflow/implementation-plan.md
• docs/workflow/implementation-handoff.md

実行手順

1. 受入条件と検証コマンドの対応を確認する
2. 対象テストから広いテストへ進み、型検査・Lint・ビルドを実行する
3. 失敗は再現条件を残し、修正後に影響する検証を再実行する
4. 最新差分の結果を受入条件ごとに記録する

期待成果物

• docs/workflow/test-evidence.md
• コマンド、対象差分、結果、失敗時の再現条件、受入条件との対応

終了条件

• 必須のテスト・型検査・Lint・ビルドが最新差分に対して成功している
• 未検証項目がないか、判断者が承認した例外として記録されている

失敗時の戻り先

• 実装起因の失敗は実装へ戻し、修正後に検証を再実行する
• 検証方法がない場合は計画へ戻る
• 受入条件が観測不能なら要件理解へ戻る

Before / After

Before: 従来のやり方

• 「たぶん動く」という主観的な判断で完了宣言
• テストを実行しても結果を確認しない
• 一部のテストが失敗しているのに「OK」と報告
• 手動でブラウザを開いて目視確認

After: ツール活用後

• テスト実行結果のコマンド出力を直接確認してから完了宣言
• プロジェクトが定めたカバレッジ基準を数値で確認
• E2Eテストを Playwright で自動実行
• 品質ゲートを通過しないと先に進めない

レベル別アプローチ

Beginner

Level 1 プレイブック

入力例

差分: 現在の git diff
引き継ぎ: docs/workflow/implementation-handoff.md

コマンド / プロンプト

claude

差分と引き継ぎを確認し、受入条件へ検証を対応付けてください。
下のコマンドを実行し、終了コードと要点を
docs/workflow/test-evidence.md に記録してください。失敗時は完了としないでください。

npx velite
npx tsc --noEmit
pnpm lint

生成物例

# 検証記録
- npx velite: 成功
- npx tsc --noEmit: 成功
- pnpm lint: 成功
## 未検証
なし。

検証

test -s docs/workflow/test-evidence.md
rg -n 'npx velite|npx tsc --noEmit|pnpm lint|未検証' docs/workflow/test-evidence.md

出口判定

• 最新差分の必須ゲートが成功し、受入条件から証拠を追跡できる
• 未検証項目がないか、承認済み例外として記録されている

Claude Code の Bash ツールでテストを実行・確認。

# テスト実行
Claude Code > npm run test を実行して結果を報告して

# 型チェック
Claude Code > npx tsc --noEmit を実行して

# Lint
Claude Code > npm run lint を実行して

# ビルド確認
Claude Code > npm run build を実行してエラーがないか確認

手順:

1. Bash でテストスイートを実行
2. 結果の失敗数・成功数を確認
3. Bash で型チェック・Lint・ビルドを実行
4. 全て通過したことを確認してから完了

Intermediate

Superpowers の verification-before-completion と OMC の ultraqa を活用。

# Superpowers: verification-before-completion
# IDENTIFY → RUN → READ → VERIFY → THEN claim
# 「完了」を宣言する前に必ず検証コマンドを実行して結果を確認
# 24の失敗事例から学習されたゲート機能

# OMC: ultraqa（QA サイクル）
/oh-my-claudecode:ultraqa
# test → verify → fix → repeat の自動ループ
# 全テストが通るまで自動的に修正を繰り返す

# OMC: verifier エージェント
> 実装が完了したか検証して
# 完了の証拠を収集し、タスクが完全に終わっているか確認

# OMC: qa-tester エージェント
> E2Eテストを実行して
# ランタイムと手動のバリデーション

手順:

1. Superpowers verification-before-completion のゲートフローを実行
2. テストを実行し、出力を直接読んで結果を確認
3. OMC ultraqa で test → verify → fix の自動ループ
4. OMC verifier エージェントで完了証拠を収集
5. プロジェクトが定めたカバレッジ基準を確認

Advanced

OMC のチーム検証と ECC の包括的な品質ゲートを活用。

# OMC: team パイプラインの team-verify フェーズ
/team 3:executor "機能実装"
# team-plan → team-prd → team-exec → team-verify → team-fix
# チーム全体で検証と修正をループ

# ECC: quality-gate（品質ゲート）
/quality-gate
# リポジトリ全体または特定パスの品質チェック

# ECC: verify（検証ループ）
/verify
# build → test → lint → typecheck → security の連続検証

# ECC: verification-loop スキル
# 継続的検証: ビルド、テスト、Lint、型チェック、セキュリティ

# ECC: test-coverage（テストカバレッジ分析）
/test-coverage

# ECC: eval（評価基準での評価）
/eval

# OMC: visual-verdict（UI の視覚的検証）
/oh-my-claudecode:visual-verdict

手順:

1. ECC verification-loop でビルド→テスト→Lint→型チェック→セキュリティを連続実行
2. ECC quality-gate で品質ゲートを通過
3. OMC team-verify でチーム全体の検証
4. ECC test-coverage でプロジェクトのカバレッジ基準を確認
5. OMC visual-verdict で UI の視覚的検証（該当時）

ベストプラクティス

1. 出力を直接確認する -- Superpowers verification-before-completion の核心。テストを実行しただけでなく、出力を読んで結果を確認してから完了宣言する
2. 検証は自動ループで -- OMC ultraqa や ECC verification-loop で、テスト失敗 → 修正 → 再実行を自動化する。手動での修正→再実行は非効率
3. カバレッジは数値で確認 -- 「十分なテスト」という主観ではなく、プロジェクトが定めた目標を ECC test-coverage で測定する
4. 段階的に検証 -- 単体テスト → 統合テスト → E2Eテストの順で実行。下位レベルで失敗しているのに上位テストに進まない
5. 視覚的検証も忘れずに -- UI変更がある場合は、OMC visual-verdict や ECC e2e で視覚的な検証を行う

よくある罠

「テストを実行しました」で終わり

テストを実行したことと、テストが通ったことは別。Superpowers は24の失敗事例から、「実行した」と「通った」を混同するパターンを学習している。

部分的な完了宣言

一部のテストだけが通った状態で「完了」と宣言するのは不正確。必須テストがすべて通るまで完了とは言えない。OMC ralph は「暗黙の部分完了を許さない」。

失敗テストの無視

test.skip や // @ts-ignore で失敗を隠すのは最悪のアプローチ。失敗しているテストは根本原因を調査し、修正する。

カバレッジの数字だけを見る

カバレッジ基準を満たしていても、重要なエッジケースが未検証なら不十分。数値だけでなく、どのパスがテストされているかを確認する。

E2Eテストの省略

「手動で確認したから大丈夫」は不十分。Playwright で再現可能なE2Eテストを作成し、リグレッションを防ぐ。