mcpField
V
verify

verify

github.com/ariadossテスト・品質1260 回インストール1 日前に更新
リポジトリ

verify について

verifyは、作業完了を報告する前に最新のコマンド出力を求めるソフトウェア開発向けスキルです。テスト、ビルド、回帰確認、要件の確認、エージェントの変更の独立検証を支援します。

主な機能

  1. 01最新の検証証拠を必須化
  2. 02コマンド出力全体の実行と確認
  3. 03テストとビルドの検証
  4. 04回帰と要件の確認
  5. 05エージェントの変更を独立して確認

活用シーン

  1. 01報告前にテストの合格を確認
  2. 02コミット前にビルドを検証
  3. 03回帰テストで修正を確認
  4. 04委任したエージェント作業を確認

インストール

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

$npx skills add https://github.com/ariadoss/superskills --skill verify

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

詳細

完了前の検証

概要

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

superskills の品質基準の一部です(「テストは実際に実行しなければならない」— プロジェクト内ではなく、superskills のインストール先に ENGINEERING_STANDARDS.md として記載されています)。このスキルは、「完了」を主張ではなく、新たな証拠によって証明する方法です。

基本原則:常に、主張する前に証拠を示します。

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

鉄則

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リンターに合格したこと、ログが問題なさそうなこと
バグを修正した元の症状を検証するテスト:合格コードを変更したこと、修正されたと想定すること
回帰テストが機能するRed-Green サイクルを検証したことテストに一度合格したこと
エージェントが完了したVCS の diff に変更が示されていることエージェントが「成功」と報告したこと
要件を満たした項目ごとのチェックリストテストに合格したこと

危険信号 — 停止する

  • 「はず」「おそらく」「そう見える」を使う
  • 検証する前に満足を表明する(「すばらしい!」「完璧!」「完了!」など)
  • 検証せずにコミット、プッシュ、PR をしようとしている
  • エージェントの成功報告を信頼する
  • 部分的な検証に頼る
  • 「今回だけなら」と考える
  • 疲れていて、作業を終わらせたいと思っている
  • 検証を実行せずに成功を示唆する表現を使うこと

正当化を防ぐ

言い訳実際
「これで動くはず」検証を実行する
「自信がある」自信 ≠ 証拠
「今回だけなら」例外はありません
「リンターには合格した」リンター ≠ コンパイラー
「エージェントが成功したと言った」自分で検証する
「疲れている」疲労 ≠ 言い訳
「部分的なチェックで十分」部分的なチェックでは何も証明できません
「別の言葉だから、このルールは適用されない」文言より趣旨を重視する

主なパターン

テスト:

✅ [Run test command] [See: 34/34 pass] "All tests pass"
❌ "Should pass now" / "Looks correct"

回帰テスト(TDD の Red-Green):

✅ 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 の作成、タスクの完了
  • 次のタスクへの移行
  • エージェントへの委任

ルールの適用対象:

  • そのままの表現
  • 言い換えや類義語
  • 成功を示唆する表現
  • 完了や正確性を示唆するあらゆるコミュニケーション

要点

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

コマンドを実行します。出力を読みます。その後で結果を主張します。

これは譲れないルールです。

コメント