Menü
レビュー完了後の最終検証に使用。テスト結果・要件充足・スコープ逸脱がないことを証拠付きで確認し、完了宣言の根拠を作る。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
実装完了後のコードレビューに使用。仕様準拠・コード品質・セキュリティの3観点を並列レビューし、指摘を依存解決して修正する。
セッション完了後の振り返りに使用。ワークフロー遵守の検証、ユーザ指摘の収集と自己改善提案、改善後のリグレッション確認を行う。
ワークフローを開始する。ユースケースを選択し、適切なステップを順に実行する
設計確定後、実装前に使用。設計をタスクに分解し、実装順序と依存関係を明確にする。
大規模プロジェクト（複数機能・フェーズ分割が必要）で使用。全体をフェーズに分割し、マイルストーンとリスクを定義する。各フェーズは planning スキルに渡す。
機能開発・バグ修正の着手前に使用。メインセッションで人間パートナーと対話し、要件を構造化する。コード調査は Explore エージェントに委譲。
| 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 — 検証エージェントの詳細レポート（間接検証や人手検証の記録）前提スキル:
必須ルール:
次のステップ:
このスキルの出力を参照するエージェント: