verification-loop

verification-loop の概要

verification-loop は何のためのものか

verification-loop は、Claude Code セッション向けの検証ワークフローです。実装後の変更を、単なる「問題なさそうです」といった一発の確認に頼らず、ビルド、型、lint、テスト、セキュリティ、diff レビューを意図的な順序で回して確認できるようにします。Verification 用の verification-loop skill を探しているなら、これは機能設計そのものではなく、PR 前にリグレッションを見つけることを狙ったものです。

どんな人に向いているか

JavaScript、TypeScript、Python のプロジェクトでコード変更をよく仕上げるなら、verification-loop は有効です。特に、ビルド失敗や型エラーが後続ステップを止めるべきだと考えるエージェントや開発者に向いており、明確な停止条件を持つ構造化された変更後チェックを求める場合に役立ちます。

何が違うのか

verification-loop の主な価値は、段階的な進め方にあります。まずビルド、次に型、そして lint、テスト、セキュリティチェック、最後に diff レビューという順番です。この順序には意味があります。無駄な作業を減らせて、失敗箇所の切り分けもしやすくなるからです。また、この skill は報告内容にもかなり明確な意見を持っており、テスト件数やカバレッジのような出力期待値がはっきりしているため、曖昧な検証プロンプトよりも判断しやすくなっています。

verification-loop skill の使い方

verification-loop のインストールとセットアップ

verification-loop skill を Claude Code 環境にインストールしたら、まず SKILL.md を開いて出発点にします。リポジトリは最小構成なので、補助スクリプトやサポート用フォルダに頼る前提はありません。skill 自体が唯一の正本です。verification-loop install の実際の目的は、skill を追加することだけではなく、今使っているプロジェクトに、このワークフローが想定する build と test のコマンドが揃っているかを確認することです。

skill に具体的な変更コンテキストを与える

verification-loop usage が最もよく機能するのは、変更内容、技術スタック、適用すべき検証コマンドを具体的に伝えたときです。弱い入力は「コードを検証して」です。より強い入力は「この TypeScript アプリの login リファクタを検証して。build、tsc --noEmit、lint、test を実行し、失敗内容をファイル名付きで要約して、マージして安全かどうかも示して」のようなものです。ここまで具体的にすると、何を確認すべきか、何がブロッカーに当たるかを skill が判断しやすくなります。

フェーズ順と停止ルールを守る

フェーズは順番に実行し、早い段階で失敗したら先へ進まないでください。build が失敗したら type check の前にそこを直し、型が落ちたら lint や test の確認に進む前に重大なエラーを解消します。これが verification-loop ガイドの中核です。並列に全部見るのではなく、絞り込みながら進めるワークフローなのです。

先に読むべきファイル

まず skills/verification-loop/SKILL.md を読みます。実際のコードベースに合わせて調整するなら、そこに書かれたコマンドをプロジェクトの package scripts や既存のツールチェーンと突き合わせてください。この repo には追加の参照資料がないため、次に読むべきなのはプロジェクト側の build、lint、test 定義です。npm、pnpm、ruff、pyright が本当に使えると決めつけず、実際のコマンドにマッピングする必要があります。

verification-loop skill の FAQ

verification-loop は Claude Code 専用ですか？

Claude Code セッション向けに書かれていますが、その検証ロジック自体は変更後チェックリストとして広く使えます。Claude Code の外でも、同じ手順を手動で回すことは可能です。verification-loop をインストールする主な理由は、Claude のワークフロー内での手軽さと一貫性にあります。

JavaScript や Python のプロジェクトでないと使えませんか？

いいえ。ただし、その 2 つは skill 名で明示されているスタックです。verification-loop skill が最も強いのは、build、type check、lint、test の各コマンドがはっきりしているプロジェクトです。別のツール群を使うスタックでもワークフロー自体は使えますが、コマンドの読み替えは自分で行う必要があります。

verification-loop に向かないのはどんなときですか？

小さな変更に対して一回だけのプロンプトが欲しいだけなら、あるいはリポジトリに意味のある build/test ゲートがないなら、導入は見送ってよいでしょう。標準的な検証コマンドに当てはめにくいほど独自性の強いコードベースで、ワークフローを調整したくない場合も向きません。そういうケースでは、完全な verification-loop skill を入れるより、カスタムプロンプトのほうが速いことがあります。

通常のプロンプトと比べて何が違いますか？

普通のプロンプトでも「テストを実行して」とは言えますが、verification-loop には順序立った検証ループ、明確な停止ロジック、報告目標があります。そのため曖昧さが減り、変更を出してよい状態かどうかの判断もしやすくなります。代わりに、プロジェクト固有のコマンドと制約は自分できちんと渡す必要があります。

verification-loop skill を改善する方法

プロジェクト固有のコマンドを与える

品質を最も大きく上げるのは、一般的なコマンドを、リポジトリが実際に使っているものに置き換えることです。プロジェクトで pnpm build、npm test、pytest、あるいは独自スクリプトを使っているなら、最初にそれを伝えてください。入力が具体的であるほど推測が減り、verification-loop はデフォルトのコマンド列より信頼できます。

合否だけでなく失敗要約を求める

失敗したステップ、ファイル名、そしてマージを止めるべきかどうかを含む簡潔なレポートを求めると、skill はより実用的になります。たとえば「ループ実行後、build エラー、type の問題、test failure の順で並べ、どれが critical かも示して」と指示します。そうすると、出力が二択の判定ではなく、次に何を直すべきか分かる実用的な情報になります。

よくある失敗パターンに注意する

よくある問題は、プロジェクトのコマンドが足りないこと、型チェックの範囲が不完全なこと、そしてセキュリティスキャンがリポジトリに対して浅すぎることです。もう一つの失敗パターンは、コードがまだ安定していない段階で変更検証をさせることです。verification-loop が最も力を発揮するのは、実装が終わって diff を判断できる状態になってからです。

最初の実行後に繰り返し調整する

最初の検証でノイズが多かったら、次回は範囲を絞ってください。変更ファイルを明示し、対象の package や app ディレクトリを指定し、許容できる警告も明確にします。最初の実行が通っても変更をまだ信用しきれないなら、危険なファイル、エッジケース、カバレッジの抜けに焦点を当てた diff レビューを求めてください。そうすることで、verification-loop は一回きりのチェックリストではなく、繰り返し使える検証ルーチンになります。