verification-before-completion について
ソフトウェア作業の状況や完了を報告する前に、検証を実行し、その出力を確認するためのスキルです。テスト、ビルド、修正、要件に関する主張を、それぞれの証拠に結び付けます。
主な機能
- 01完了を主張する前に最新の検証を実行
- 02出力全体・終了コード・失敗数を確認
- 03テスト・ビルド・修正に必要な証拠を明示
- 04要件を個別に確認し不足を報告
- 05エージェントの報告とバージョン管理差分を検証
活用シーン
- 01テスト結果を報告する前にテストを実行
- 02コード提出前にビルド結果を確認
- 03元の症状に照らして修正を検証
- 04エージェントの変更と要件の充足状況を確認
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ makerjackie/ jackie-skills-starter --skill verification-before-completionインストール後、Claude Code で/verification-before-completionを入力して読み込まれたか確認します。
詳細
完了前の検証
概要
検証せずに作業が完了したと主張するのは、効率化ではなく不誠実です。
基本原則: 常に、主張する前に証拠を示してください。
このルールの文言に違反することは、このルールの精神に違反することです。
絶対的なルール
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 行ずつ確認するチェックリスト | テストに合格したこと |
危険信号 — 停止してください
- 「はず」「たぶん」「どうやら」を使う
- 検証する前に満足を表明する(「すばらしい!」「完璧!」「完了!」など)
- 検証せずにコミット、プッシュ、PR をしようとしている
- エージェントの成功報告を信頼する
- 部分的な検証に頼る
- 「今回だけなら」と考える
- 疲れていて、作業を終わらせたいと思っている
- 検証を実行していないのに、成功を示唆する表現を使おうとしている
正当化を防ぐ
| 言い訳 | 実態 |
|---|---|
| 「これで動くはず」 | 検証を実行してください |
| 「自信がある」 | 自信 ≠ 証拠 |
| 「今回だけなら」 | 例外はありません |
| 「リンターには合格した」 | リンター ≠ コンパイラー |
| 「エージェントが成功と言った」 | 自分で独立して検証してください |
| 「疲れている」 | 疲労 ≠ 言い訳 |
| 「部分的なチェックで十分」 | 部分的なチェックでは何も証明できません |
| 「別の言い方だから、このルールは適用されない」 | 文言より精神を優先します |
主なパターン
テスト:
✅ [Run test command] [See: 34/34 pass] "All tests pass"
❌ "Should pass now" / "Looks correct"
回帰テスト(TDD のレッド・グリーン):
✅ 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 対応