mcpField
V
validator-run

validator-run

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

validator-run について

validator-run は、明示的な検証依頼に応じて agent-validator の自動検証スイートを実行するスキルです。チェックやレビューの問題に対処し、修正後に再検証して結果をまとめます。

主な機能

  1. 01検証スイートの実行
  2. 02明示的なステータス出力の確認
  3. 03チェックとレビュー失敗への対応
  4. 04レビュー判断の記録
  5. 05修正後の再検証

活用シーン

  1. 01コミット前の変更検証
  2. 02プルリクエスト前の依頼されたチェック
  3. 03検証で見つかった問題の解消

インストール

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

$npx skills add https://github.com/codagent-ai/agent-validator --skill validator-run

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

詳細

/validator-run

自律検証スイートを実行します。

呼び出しポリシー

このスキルは、「run the validator」「run the gauntlet」「run validation」「validate this」「validate before commit/push/PR」など、明示的な検証リクエストに対してのみ使用してください。

コーディングタスクが完了したというだけの理由、ユーザーが一般的なレビューを求めたというだけの理由、またはユーザーがチェックのみを求めたというだけの理由でこのスキルを選択しないでください。

手順

ステップ 1 - エージェントバリデータを実行する

呼び出し元が特定のレビューを有効にするよう要求した場合は、要求された各レビューについて、実行コマンドに --enable-review <name> を追加してください。

Bash を使用して、timeout: 300000 で agent-validate run を実行します。続行する前に、必ずコマンド出力を最後まで待って読み取ってください — このコマンドは通常 1~2 分かかります。続行する前に、出力に Status: 行があることを確認してください。

ステップ 2 - ステータスを確認する

成功したと決して決めつけないでください — 続行する前に、明示的な Status: 行を確認する必要があります。それを確認し、次のように振り分けてください。

  • Status: Passed → ステップ 8 へ進みます。
  • Status: Passed with warnings → ステップ 8 へ進みます。
  • Status: Failed → ステップ 3 へ続けます。必ず続行してください — ここで停止しないでください。
  • Status: Retry limit exceeded → ステップ 8 へ進みます。
  • ステータス行が見えない → 既知の問題: LLM レビューのサブプロセスが実行されると、Bun が stdout/stderr をすべて破棄することがあります。ステータスを取得するにはコンソールログファイルを読み取ってください。バリデータログディレクトリ内の最新の console.*.log(例: validator_logs/console.1.log)を見つけ、そこにある Status: 行を探します。そこにコンソールログが見つからない場合は、直近にアーカイブされた実行のログについて validator_logs/previous/ も確認してください。どちらの場所にもコンソールログが存在しない場合、コマンドがタイムアウトしたか実行に失敗した可能性があります — より長いタイムアウトで再実行するか、エラーを調査してください。成功したものとして続行しないでください。
ステップ 3 - 失敗を抽出する

ステータスが Failed のときに必要です。

  • REVIEW 違反について、Bash で agent-validate update-review list を実行してください。保留中の各違反の ID、優先度、ゲート、file:line、問題、および推奨される修正が出力されます。それらの ID をステップ 6 のために保持してください。
  • 失敗した各 CHECK について、実行がコンソールの [FAIL] 出力またはその --report の CHECK FAILURES セクションで報告するもののみを使用してください。つまり、チェックのコマンド、Fix Instructions または Fix Skill、およびログのパスです。エラー出力を確認するには、その名前の付いたログファイルを 1 つ読み取るか、報告されたコマンドを再実行してください。コマンドを再実行する際は、報告された作業ディレクトリに従ってください。
  • ログディレクトリを一覧表示したりスキャンしたりしないでください。レビューの JSON ファイルを読み取らないでください。
ステップ 4 - 失敗を報告する

ステップ 3 のチェック失敗と update-review list の出力を、各レビュー違反の ID を含めて出力してください。

ステップ 5 - 修正する

フィードバックによって合理的に裏付けられる問題、または人間が意図していた可能性が高い問題を修正してください。問題をスキップする場合は、何をスキップし、なぜスキップするのかを簡潔に述べてください。

スキップする正当な理由:

  • 純粋にスタイル上または主観的な好み
  • 人間が変更を望まないであろう場合

これらの理由でスキップしてはなりません:

  • 「問題は以前から存在する」 — 別の正当な理由がない限り、必ず修正してください
  • 「問題はスコープ外である」 — リファクタリングや非自明な変更が必要であっても、正当なフィードバックには必ず対処してください

各失敗に対してこの指針を適用し、それに応じて修正してください。

  • Fix Skill がある CHECK 失敗: 指定されたスキルを呼び出します
  • Fix Instructions がある CHECK 失敗: 指示に従います
  • REVIEW 違反: 上記の指針に従って修正またはスキップします
ステップ 6 - レビューの判断を更新する

対処した各 REVIEW 違反について、ステップ 3 の ID を使用してください。ID を更新する必要がある場合にのみ、agent-validate update-review list を再度実行してください。各判断を agent-validate update-review fix <id> "<what changed>" または agent-validate update-review skip <id> "<why>" で記録してください。

ID は次回のバリデータ実行まで安定しています。ステップ 7 の前にすべての判断を記録してください。

validator_logs/ または設定されたログディレクトリ配下のファイルを直接編集しないでください。 レビューの判断には update-review を使用してください。

ステップ 7 - 検証を再実行する

このステップを決してスキップしないでください — 実行が失敗した場合は、必ず修正して再実行する必要があります。ステップ 1 と同じコマンド(--enable-review フラグがある場合はそれも含む)を Bash と timeout: 300000 で再度実行してください。ツールは既存のログを検出し、自動的に検証モードに切り替わります。ステップ 2 に戻り、ステータス行を確認して繰り返してください。

ステップ 8 - セッションを要約する

セッションの要約を提供してください:

  • 最終ステータス: (合格 / 警告ありで合格 / 再試行回数の上限超過)
  • 修正された問題: (主な修正を列挙)
  • スキップされた問題: (スキップされた項目とその理由を列挙)
  • 未解決の失敗: (再試行回数の上限を超えた場合、未検証の修正と残りの問題を列挙)

コメント