mcpField
V
verification-before-completion

verification-before-completion

github.com/pixel-process-ugテスト・品質382 回インストール33 週間前に更新
リポジトリ

verification-before-completion について

開発タスクの完了前に確認するスキルです。完了を宣言する前に、最新の検証コマンドを実行して出力全体を読み、5段階の手順でテストやビルド結果が主張を裏付けるか確認します。

主な機能

  1. 01該当する検証コマンドの特定
  2. 02最新の全検証の実行
  3. 03コマンド出力全体の確認
  4. 04結果と完了宣言の照合
  5. 05検証証拠の記録

活用シーン

  1. 01コード提出前のテスト・ビルド確認
  2. 02不具合修正後の変更再検証
  3. 03設定変更やリファクタリングの検証

インストール

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

$npx skills add https://github.com/pixel-process-ug/superkit-agents --skill verification-before-completion

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

詳細

概要

検証してから完了とするスキルは、ツールキット内のすべてのタスクにおける最終チェックポイントです。新たに検証コマンドを実行し、その出力全体を読み、結果が完了の報告と一致することを確認する、厳格な5段階のプロトコルを徹底します。このスキルがなければ、エージェントは検証していない内容を完了したと報告し、本番環境でコードの不具合を引き起こします。このスキルがあれば、あらゆる完了報告が証拠に裏付けられます。


鉄則

新たな検証の証拠なしに、完了を報告してはいけません。

このセッションで検証コマンドを実行し、その出力を読まずに、「動作します」「完了しました」「バグを修正しました」「機能が完成しました」と言うことはできません。キャッシュされた結果、以前の実行結果、推測は証拠になりません。


フェーズ1:検証コマンドを特定する

何かを実行する前に、今回のタスクで合格する必要があるものを明確に列挙します。

検証の種類コマンドの例必要な場合
単体テストnpm test、pytest、go test ./...、cargo test、php artisan test常に
統合テストnpm run test:integration、pytest tests/integration/該当する場合
型チェックtsc --noEmit、mypy .、pyright、phpstan analyseプロジェクトで型チェックを使用する場合
リントeslint .、ruff check .、golint ./...、php-cs-fixer fix --dry-run常に
ビルドnpm run build、cargo build、go build ./...常に
フォーマットチェックprettier --check .、black --check .、gofmt -l .、pint --testプロジェクトでフォーマッターを使用する場合

実施事項: 現在のプロジェクトに該当する項目を列挙してください。すべての種類を備えているプロジェクトばかりではありません。何を実行するのか、またその理由を明確にしてください。

停止:該当する検証の種類をすべて特定するまで、コマンドの実行に進んではいけません。


フェーズ2:コマンドを新たに実行する

フェーズ1で特定した検証コマンドをすべて実行します。

ルール理由
最新のコード変更後に実行する変更前の結果は古くなっています
一部ではなく、スイート全体を実行する一部だけの実行ではリグレッションを見落とします
キャッシュされた結果に頼らない前回の実行後にコードが変更されています
「以前合格したから」といってコマンドを省略しない以前と今は同じではありません
コマンドに5分を超える時間がかかる場合は、その旨を記録する代わりに何を実行したのか説明します

停止:フェーズ3に進む前に、すべてのコマンドを完了させてください。


フェーズ3:出力全体を読む

各検証コマンドの出力全体を読みます。次の点に注意してください。

出力要素確認する内容重要な理由
終了コード0以外は失敗です出力に問題がなさそうでも、0以外なら何かが失敗しています
テスト数想定した数のテストが実行されましたか?スキップされたものはありますか?スキップされたテストがあると、テストされていないコードが残ります
警告メッセージ以前はなかった新しい警告がないか警告はエラーになる可能性があり、品質の低下を示しています
非推奨の通知非推奨のAPIが使われていないか将来の不具合につながるリスクがあります
パフォーマンスの指標通常より遅いテストがないかパフォーマンスのリグレッションを示している可能性があります
エラーメッセージテストが「合格」していても、エラーがないかテストが合格する一方で、エラーも報告するフレームワークがあります

停止:すべてのコマンドの出力全体を読んでいない場合は、先に進んではいけません。


フェーズ 4:出力が主張と一致することを検証する

次の質問を自問してください。次に進むには、すべて「はい」でなければなりません。

質問「いいえ」または「不明」の場合
作成したテストだけでなく、すべてのテストが合格していますか?完了を宣言する前に、失敗したテストを修正します
ビルドはエラーなく成功しますか?ビルドエラーを修正します
型チェッカーはエラーを検出しませんか?型エラーを修正します
リンターは合格しますか?リントエラーを修正します
以前はなかった新しい警告はありますか?調査して修正するか、明確に正当化します
一部だけでなく、テストスイート全体を実行しましたか?テストスイート全体を実行します
テスト数は想定どおりですか?スキップされたテストや不足しているテストを調査します

停止:いずれかの回答が「いいえ」または「不明」の場合は、修正に戻り、フェーズ 1 からやり直してください。フェーズ 5 に進んではいけません。


フェーズ 5:証拠を添えて完了を宣言する

この時点で初めて、タスクの完了を宣言できます。次の証拠を含めてください。

VERIFICATION EVIDENCE
=====================
Task: [what was being done]
Date: [timestamp]

Commands Run:
  [x] Tests:      [command] -> [result: X passed, Y failed, Z skipped]
  [x] Build:      [command] -> [result: success/failure]
  [x] Lint:       [command] -> [result: X errors, Y warnings]
  [x] Type-check: [command] -> [result: X errors]
  [x] Format:     [command] -> [result: clean/X files to format]

All Green?  [x] YES  [ ] NO
New warnings introduced?  [ ] YES  [x] NO

Completion claim: [specific claim, e.g., "Feature X is implemented and all tests pass"]

停止:これで検証プロトコルは終了です。この証拠を伴う主張のみが有効です。


判断表:「新しい」証拠とみなされるもの

新しい証拠とみなされる新しい証拠とみなされない
最新のコード変更後にコマンドを実行した最新のコード変更前に実行した
テストスイート全体を実行した一部のテストのみ実行した
出力を読み、分析した出力に目を通しただけ、または無視した
すべての検証種別を実行したテストのみ実行した(リントもビルドも実行していない)
現在のセッションでコマンドを実行した前のセッションの記憶をたどった
実際のコマンド出力を確認できる「合格したと覚えている」

判断表:例外的なケース

状況プロトコル
テストスイート全体の実行に 5 分以上かかる関連するテストとスモークテストを実行します。テストスイート全体は実行していないことを明記します。マージ前に CI で実行することを推奨します。
自動テストが存在しない重大なリスクとして記載します。手順を文書化したうえで、手動検証を行います。後続対応としてテストの追加を推奨します。少なくとも、コードがコンパイルされ、実行できることを確認します。
テストが不安定である失敗したテストを単独で再実行します。単独では合格する場合は、不安定であることを記載します。変更によって不安定さが生じていないことを確認します。不安定さを理由にテストを省略してはいけません。
設定のみの変更設定変更は障害の最大の原因です。完全な検証が必要です。
1 行だけの変更1 行の変更でも本番障害が発生することがあります。完全な検証が必要です。
リファクタリングのみ既存のテストが引き続き合格する必要があります。テストスイート全体を実行します。

よくある失敗パターン

パターン起きること危険な理由
テストは合格するが、リントは失敗するコードは動作するが、品質に問題があるリントの失敗は、実際の問題(未使用の変数、到達不能なコードなど)を示していることがよくあります
テストは合格するが、ビルドは失敗するテスト環境とビルド環境が異なる本番環境へのデプロイが失敗します
テストは合格するが、型チェックは失敗する実行時は動作するが、型が誤っているany 型や誤ったインターフェースに潜むバグ
テストを単独で実行すると合格するが、まとめて実行すると失敗するテスト間で状態を共有しているCI が不安定になり、テストスイートの信頼性が低下します
手動テストは合格するが、自動テストは失敗する手動テストでエッジケースを見落とした自動テストの結果が正しい
テストは合格するが、新しい警告が現れた何かが悪化した警告は時間の経過とともにエラーになります
一部のテストのみ合格する関連するテストしか実行していない無関係な領域でリグレッションが起きている可能性があります
テストは合格するが、カバレッジが低下した新しいコードがテストされていないテストされていないコードは検証されていないコードです
古いテスト実行結果を証拠として使う結果が古くなっているその実行後にコードが変更されています
「コンパイルできたので、動作する」コンパイルは必要ですが、十分ではありませんコンパイルできたコードでも、誤っている可能性があります

アンチパターン/よくある間違い

やってはいけないことうまくいかない理由代わりにすること
テストを実行せずに完了を宣言する検証されていないコードは本番環境で問題を起こしますすべての検証コマンドをその都度実行します
「以前は成功した」を根拠にするその後、コードが変更されています変更のたびに新たに実行します
「警告にすぎない」とリントを省略する警告は実際の問題を示しています警告を修正するか、それぞれに明確な理由を示します
自分で書いたテストだけを実行するほかの領域でのリグレッションを見逃しますテストスイート全体を実行します
テスト出力を一部だけ読む出力内に隠れた失敗を見逃します出力のすべての行を読みます
手動テストだけを根拠にする手動テストは不完全で、再現できません自動検証を実行します
一度検証した後に「小さな」変更を追加するその変更は検証されていません変更のたびに再検証します
コメントなしで警告を抑制する実際の問題を隠してしまいます本当に誤検知であれば、その理由を説明する抑制コメントを追加します

言い訳を防ぐための確認事項

言い訳実態
「1行しか変更していません」1行の変更でも本番障害の原因になります。検証してください。
「5分前にテストが通りました」その後、変更を加えています。もう一度実行してください。
「このパターンは以前テストしました」今回は別のケースです。このケースを検証してください。
「変更内容は明らかに正しいです」明らかに見える変更ほど、検証されずに失敗することがよくあります。
「テストの実行に時間がかかりすぎます」バグが本番環境に到達してからの対応のほうが、テストを実行しないより時間がかかります。
「提出後に検証します」実際には検証しないでしょう。検証に失敗したら、元に戻してやり直すことになります。
「設定を変更しただけです」設定変更は障害の原因の第1位です。検証してください。
「リンターの警告は誤検知です」1つずつ確認してください。本当に誤検知であれば、コメント付きで抑制してください。
「型エラーは無関係なコードで発生しています」相互に影響する可能性があります。全体チェックを実行してください。
「手動でテストしました」手動テストは不完全で、再現できません。自動検証を実行してください。

Phase 5 の証拠なしに完了を宣言してはいけません。例外は一切ありません。


統合ポイント

スキル検証が必要なタイミング
test-driven-development機能の RED-GREEN-REFACTOR サイクルの完了後
systematic-debuggingバグ修正の適用後
executing-plans各タスクの後、および各バッチの後
subagent-driven-development実装担当者が(Agent ツールを介して)成果物を提出した後、レビュアーの承認後
code-reviewコードレビューを承認する前
resilient-executionタスクを完了としてマークする前
autonomous-loopEXIT_SIGNAL を true に設定する前
finishing-a-development-branchマージまたは PR 作成の前
統合フロー
[Do the work using other skills]
    |
    v
[Think you are done?]
    |
    v
[Invoke verification-before-completion]
    |
    +-- All checks pass -> Claim completion with Phase 5 evidence
    |
    +-- Any check fails -> Fix and re-verify (do NOT claim completion)

他のスキルによる適用

このスキルは、完了時にほかのすべてのスキルから呼び出されます。任意ではありません。これは最終チェックポイントであり、作業の最初ではなく最後に呼び出されます。


スキルの種類

RIGID — 5段階のプロトコルは必須のゲートです。すべての手順を順番どおりに実行しなければなりません。省略できる手順はありません。Phase 5 の証拠なしに完了を宣言することはできません。いかなる理由でも、これらの要件を緩和してはいけません。

コメント