mcpField
V
verification-before-completion

verification-before-completion

github.com/jackspaceテスト・品質1636 回インストール12 週間前に更新
リポジトリ

verification-before-completion について

AI エージェントが作業完了を報告する前に、最新かつ完全な検証結果を求めるスキルです。テスト、ビルド、回帰、要件、委任作業の確認を扱います。

主な機能

  1. 01完了報告前に最新の検証を必須化
  2. 02全チェックを実行し出力と終了コードを確認
  3. 03証拠と推測を区別
  4. 04レッド・グリーンサイクルで回帰を検証
  5. 05報告前に変更と要件を確認

活用シーン

  1. 01テストやビルドの状態を報告前に確認
  2. 02元の症状で修正を検証
  3. 03完了報告前に委任先エージェントの作業を確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/jackspace/claudeskillz --skill verification-before-completion

インストール後、Claude Code で/verification-before-completionを入力して読み込まれたか確認します。

同梱ファイルSKILL.json

詳細

完了前の検証

概要

検証せずに作業完了を主張することは、効率化ではなく不誠実です。

中核原則: 主張の前に必ず証拠を示すこと。

このルールの文面に違反することは、このルールの趣旨に違反することです。

鉄の掟

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 の差分に変更が表示されるエージェントが「成功」と報告した
要件を満たした項目ごとのチェックリストテストが通っていること

危険信号 - 停止

  • 「はず」「おそらく」「のようだ」を使う
  • 検証の前に満足を表明する(「素晴らしい!」「完璧!」「完了!」など)
  • 検証せずにコミット・プッシュ・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 作成、タスク完了
  • 次のタスクへの移行
  • エージェントへの委任

ルールの適用対象:

  • 正確な言い回し
  • 言い換えや同義語
  • 成功を含意する表現
  • 完了や正しさを示唆するあらゆる伝達

結論

検証に近道はありません。

コマンドを実行し、出力を読んでから、結果を主張してください。

これは交渉の余地のないルールです。

コメント