verification-before-completion について
開発タスクの完了前に確認するスキルです。完了を宣言する前に、最新の検証コマンドを実行して出力全体を読み、5段階の手順でテストやビルド結果が主張を裏付けるか確認します。
主な機能
- 01該当する検証コマンドの特定
- 02最新の全検証の実行
- 03コマンド出力全体の確認
- 04結果と完了宣言の照合
- 05検証証拠の記録
活用シーン
- 01コード提出前のテスト・ビルド確認
- 02不具合修正後の変更再検証
- 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-loop | EXIT_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 の証拠なしに完了を宣言することはできません。いかなる理由でも、これらの要件を緩和してはいけません。