verification-before-completion について
エージェントが完了や肯定的な状況を報告する前に、最新かつ完全な検証証拠を求めるスキルです。一般的な主張と、それを裏付けるチェック方法を対応付けます。
主な機能
- 01主張前に検証するルール
- 02主張と検証コマンドの対応付け
- 03出力全体と終了コードの確認
- 04回帰テストのレッド・グリーン手順
- 05よくある検証上の誤り
活用シーン
- 01テスト合格の報告前にチェック
- 02成功を主張する前のビルド検証
- 03症状に対応したテストによる修正確認
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ jamditis/ claude-skills-journalism --skill verification-before-completionインストール後、Claude Code で/verification-before-completionを入力して読み込まれたか確認します。
同梱ファイルagents/openai.yaml
詳細
完了前の検証
概要
検証せずに作業が完了したと主張するのは、効率ではなく不誠実です。
基本原則: 常に、主張より先に証拠を示します。
このルールの文言だけでなく、精神に反することもルール違反です。
鉄則
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
このメッセージに記載された検証コマンドを実行していない場合、合格したと主張することはできません。
ゲート機能
BEFORE claiming any status or expressing satisfaction:
1. IDENTIFY: What command proves this claim?
2. RUN: Execute the FULL command (fresh, complete)
3. READ: Full output, check exit code, count failures
4. VERIFY: Does output confirm the claim?
- If NO: State actual status with evidence
- If YES: State claim WITH evidence
5. ONLY THEN: Make the claim
Skip any step = lying, not verifying
よくある失敗
| 主張 | 必要なもの | 十分ではないもの |
|---|---|---|
| テストに合格 | テストコマンドの出力:失敗 0 件 | 以前の実行結果、「合格するはず」 |
| リンターのエラーがない | リンターの出力:エラー 0 件 | 部分的なチェック、推測 |
| ビルドに成功 | ビルドコマンド:終了コード 0 | リンターの合格、ログの見た目がよいこと |
| バグを修正 | 元の症状を再現するテスト:合格 | コードを変更したこと、修正されたという思い込み |
| 回帰テストが機能 | レッド・グリーンサイクルの検証 | テストに一度合格したこと |
| エージェントが完了 | VCS の差分に変更があること | エージェントの「成功しました」という報告 |
| 要件を満たした | 1 行ずつ確認したチェックリスト | テストに合格したこと |
危険信号 - STOP
- 「はず」「たぶん」「〜のようです」を使う
- 検証前に満足を表す(「すばらしい!」「完璧!」「完了!」など)
- 検証せずにコミット、プッシュ、PR をしようとしている
- エージェントの成功報告を信頼している
- 部分的な検証に頼っている
- 「今回だけなら」と考えている
- 疲れていて作業を終わらせたいと思っている
- 検証を実行せずに成功を示唆する表現は、どんなものでも
正当化の防止
| 言い訳 | 現実 |
|---|---|
| 「今度は動くはず」 | 検証を実行する |
| 「自信がある」 | 自信 ≠ 証拠 |
| 「今回だけなら」 | 例外はありません |
| 「リンターは通った」 | リンター ≠ コンパイラー |
| 「エージェントが成功したと言った」 | 自分で独立して検証する |
| 「疲れている」 | 疲労 ≠ 言い訳 |
| 「部分的なチェックで十分」 | 部分的なチェックでは何も証明できません |
| 「言葉が違うからルールは適用されない」 | 文言より精神を重視する |
主なパターン
テスト:
✅ [Run test command] [See: 34/34 pass] "All tests pass"
❌ "Should pass now" / "Looks correct"
回帰テスト(レッド・グリーン):
✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
❌ "I've written a regression test" (without red-green verification)
ビルド:
✅ [Run build] [See: exit 0] "Build passes"
❌ "Linter passed" (linter doesn't check compilation)
要件:
✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
❌ "Tests pass, phase complete"
エージェントへの委任:
✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
❌ Trust agent report
これが重要な理由
24 件の失敗の記憶から:
- 人間のパートナーに「あなたの言うことは信じられない」と言われ、信頼が壊れました
- 未定義の関数が出荷され、クラッシュするところでした
- 要件の不足した機能が出荷されました
- 誤った完了報告 → 差し戻し → やり直しに時間が浪費されました
- 次の言葉に違反します:「誠実さは核となる価値です。嘘をつけば、あなたは置き換えられます。」
適用するタイミング
必ず、次の前に:
- 成功や完了を主張する表現全般
- 満足を表す表現全般
- 作業の状態について肯定的に述べる表現全般
- コミット、PR の作成、タスクの完了
- 次のタスクへの移行
- エージェントへの委任
ルールの適用対象:
- そのままの表現
- 言い換えや同義語
- 成功をほのめかす表現
- 完了や正しさを示唆するあらゆるコミュニケーション
要点
検証に近道はありません。
コマンドを実行し、出力を読み、その後で結果を主張してください。
これは交渉の余地がありません。
コメント
Markdown 対応