Menu
レビュー完了後の最終検証に使用。テスト結果・要件充足・スコープ逸脱がないことを証拠付きで確認し、完了宣言の根拠を作る。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | verification |
| description | レビュー完了後の最終検証に使用。テスト結果・要件充足・スコープ逸脱がないことを証拠付きで確認し、完了宣言の根拠を作る。 |
「完了した」と言える根拠を作る。 テストが通る、レビューが通った、だけでは完了ではない。要件を全て満たし、スコープを逸脱していないことを証拠付きで確認する。
入力: REQ パス（例: requirements/REQ-001/）+ レビュー完了済みの実装コード + テストコード + requirements.md 全文 + レビュー報告
出力: 検証報告書（全 FR/AC の充足証拠 + スコープ確認 + 最終テスト結果）
原則: 「テストが通っている」は検証ではない。「要件が全て満たされている」が検証だ。
検証証拠なしに完了を宣言するな
レビューが通った ≠ 完了。レビューは品質を検証する。verification は要件充足を検証する。
常に:
例外（人間パートナーに確認すること）:
digraph verification {
rankdir=TB;
input [label="レビュー完了\nMUST指摘なし", shape=ellipse];
test [label="テストスイート\n全体実行", shape=box, style=filled, fillcolor="#ccffcc"];
fr_check [label="FR充足チェック\n各FRに対応する証拠", shape=box, style=filled, fillcolor="#cce5ff"];
ac_check [label="AC充足チェック\n各ACのテスト結果", shape=box, style=filled, fillcolor="#cce5ff"];
scope_check [label="スコープチェック\nやらないことを実装していないか", shape=box, style=filled, fillcolor="#ccccff"];
report [label="検証報告書\n作成", shape=box, style=filled, fillcolor="#ffffcc"];
judge [label="全項目\n充足?", shape=diamond];
done [label="検証完了\n完了宣言可能", shape=ellipse];
fail [label="不足箇所を\n報告→差し戻し", shape=box, style=filled, fillcolor="#ffcccc"];
input -> test;
test -> fr_check;
fr_check -> ac_check;
ac_check -> scope_check;
scope_check -> report;
report -> judge;
judge -> done [label="はい"];
judge -> fail [label="いいえ"];
}
全テストを実行し、GREEN であることを確認する。
requirements.md の各 FR（機能要件）に対して、実装が存在する証拠を確認する。
| 確認項目 | 方法 |
|---|---|
| FR の振る舞い（WHEN） | 対応するコードが実装されているか |
| FR の異常系（IF） | エラーハンドリングが実装されているか |
| FR の入力/出力 | インターフェースが仕様通りか |
各 FR に対して「充足 / 未充足 / 部分充足」を判定する。
requirements.md の各 AC（受け入れ条件）に対して、テストが存在し通っている証拠を確認する。
| 確認項目 | 方法 |
|---|---|
| AC に対応するテストの存在 | テストコード内で AC の Given/When/Then に対応するテストを特定 |
| テストの結果 | テスト実行結果で GREEN であることを確認 |
| Covers 対応 | AC の Covers: FR-x が正しく対応しているか |
各 AC に対して「テストあり GREEN / テストあり RED / テストなし」を判定する。
requirements.md の「やらないこと」「スコープ外」に記載された項目が実装されていないことを確認する。
全チェック結果を検証報告書としてまとめる。
# 検証報告書
## テスト結果
- 実行日時: [YYYY-MM-DD HH:MM]
- テスト数: [N件]
- 結果: 全GREEN / N件RED
## FR 充足状況
| FR | 状態 | 証拠 |
|----|------|------|
| FR-1 | 充足 | [対応するコード・テストの要約] |
| FR-2 | 充足 | [対応するコード・テストの要約] |
## AC 充足状況
| AC | Covers | テスト | 結果 |
|----|--------|--------|------|
| AC-1 | FR-1 | test_xxx | GREEN |
| AC-2 | FR-1 | test_yyy | GREEN |
## スコープ確認
- スコープ外の実装: なし / [あれば詳細]
## 判定
- [PASS: 全項目充足、完了宣言可能]
- [FAIL: 不足箇所あり、差し戻し]
| 言い訳 | 現実 |
|---|---|
| 「テストが通っているから検証不要」 | テストが要件の全てをカバーしているとは限らない |
| 「レビューが通ったから大丈夫」 | レビューは品質の検証。要件充足の検証は別 |
| 「小さい変更だから検証は省略」 | 小さい変更でも要件との乖離は起きる |
| 「動作確認は手動でやった」 | 記録がなければ証拠にならない。再現もできない |
| 「前回と同じパターンだから」 | 同じパターンでも要件が違えば検証項目も違う |
以下のどれかに当てはまったら、検証をやり直せ。
FR 充足チェック:
| FR | 状態 | 証拠 |
|----|------|------|
| FR-1: ユーザー登録 | 充足 | POST /users 実装済み、createUser関数でバリデーション→保存→レスポンス |
| FR-2: メール重複チェック | 充足 | findByEmail で既存ユーザー検索、409 Conflict 返却 |
| FR-3: パスワードハッシュ化 | 充足 | bcrypt.hash(password, 10) で保存前にハッシュ化 |
AC 充足チェック:
| AC | Covers | テスト | 結果 |
|----|--------|--------|------|
| AC-1: 有効な入力で登録成功 | FR-1 | test_create_user_success | GREEN |
| AC-2: メールなしでエラー | FR-1 | test_create_user_no_email | GREEN |
| AC-3: 重複メールでエラー | FR-2 | test_create_user_duplicate | GREEN |
判定: PASS — 全 FR 充足、全 AC テスト GREEN、スコープ外実装なし
検証完了前に確認:
| 問題 | 解決策 |
|---|---|
| FR に対応するコードが見つからない | 未実装の FR がある。TDD に差し戻す |
| AC に対応するテストがない | テストが漏れている。test-quality に差し戻す |
| スコープ外の機能が実装されている | 人間パートナーに報告。削除するか要件に追加するか判断を仰ぐ |
| requirements.md が不明確で判定できない | 人間パートナーに仕様の明確化を依頼する |
あなたはこのスキルのプロセスを自分で実行しない。以下のエージェントにディスパッチする。
前提: 対応する REQ を特定する。 ディスパッチ前に、このタスクに対応する requirements/REQ-*/requirements.md を特定しろ。タスクのコンテキスト（plan、直前のステップの出力）に REQ パスが含まれていればそれを使う。見つからなければ requirements/ を確認し、候補を人間パートナーに AskUserQuestion で提示して選択してもらう。推測で REQ を決めるな。必ず人間に確認しろ。
メタループ駆動の場合の例外: requirements/ が存在しない環境（workspace/ec-sample 等）では、progress.txt のストーリー定義を requirements の代替として使用する。
test-runner エージェントをディスパッチしてテスト全体実行
verifier エージェントをディスパッチする
verifier が FR 充足チェック → AC 充足チェック → スコープチェック → 検証報告書作成を実行するverifier は完了時に 4ステータス（DONE / DONE_WITH_CONCERNS / NEEDS_CONTEXT / BLOCKED）で報告するあなたが結果を判断する
あなた（コーディネーター）が検証証拠を記録する
.claude/harness/last-verification.json に Write ツールで書き出すスキーマ（必須フィールド）:
{
"status": "PASS" | "FAIL",
"timestamp": "ISO8601 UTC e.g. 2026-04-11T10:44:40Z",
"req_path": "requirements/REQ-XXX/ or improvement-proposal-N or docs/design/XXX.md",
"evidence_type": "test_run" | "integration_test" | "report",
"evidence_paths": ["path1", "path2", ...],
"reason": "1-2 行の検証結果要約"
}
任意フィールド:
{
"test_count": 103,
"test_result": "103 tests GREEN",
"notes": ["補足情報1", "補足情報2"]
}
evidence_type の使い分け:
test_run — 既存 TDD テストスイートの実行結果（node:test や bats の単体実行）integration_test — 統合テスト or E2E シナリオ（複数コンポーネントの動作確認、手動フロー含む）report — 検証エージェントの詳細レポート（間接検証や人手検証の記録）前提スキル:
必須ルール:
次のステップ:
このスキルの出力を参照するエージェント:
実装完了後のコードレビューに使用。仕様準拠・コード品質・セキュリティの3観点を並列レビューし、指摘を依存解決して修正する。
セッション完了後の振り返りに使用。ワークフロー遵守の検証、ユーザ指摘の収集と自己改善提案、改善後のリグレッション確認を行う。
ワークフローを開始する。ユースケースを選択し、適切なステップを順に実行する
設計確定後、実装前に使用。設計をタスクに分解し、実装順序と依存関係を明確にする。
大規模プロジェクト（複数機能・フェーズ分割が必要）で使用。全体をフェーズに分割し、マイルストーンとリスクを定義する。各フェーズは planning スキルに渡す。
機能開発・バグ修正の着手前に使用。メインセッションで人間パートナーと対話し、要件を構造化する。コード調査は Explore エージェントに委譲。