agent-watchdog

Agent Watchdog

ページャーを持ったレビュー担当者であり、第二の調査者でもある立場から、別のエージェントの作業を見守ります。必要に応じて完了を待ち、依頼内容を再構成し、同じ問題を独自に調査して、証拠を検証し、依頼された内容と実際に行われたことの差を埋めます。単に相手の課題を採点するのではありません。あなた自身も第二の解決者となり、その調査結果を相手の結果と差分比較して、見落としがないようにします。

モードを選択する

ユーザーの表現からモードを推測します。

• 監視のみ： セッション、PR、ブランチ、CI 実行、またはトランスクリプトが最終状態に達するまで監視します。ファイルは編集しません。
• 監査： プロンプト、トランスクリプト、差分、テスト、CI、コメント、スクリーンショット、または最終的な主張を読み、以下の独自調査を行い、差分レポートと追加対応の指示を返します。ファイルは編集しません。
• 監査して修正： まず監査を行い、明確な不足があれば必要最小限の修正をします。広範な書き換え、ブランチの移動、推測に基づく変更は避けます。
• 比較： 複数のセッションまたはエージェントが提示された場合、同じ元の依頼に照らして作業を比較し、重要な相違点を整理します。

権限が不明確な場合は、監査のみを既定とし、修正する内容を伝えます。

対象を特定する

1. ユーザーが提示した成果物をすべて特定します。セッション ID、トランスクリプトのパス、スレッド URL、PR、ブランチ、コミット、CI 実行、Issue、Slack リンク、または貼り付けられた要約などです。
2. ホスト固有のスレッド／履歴ツール、ローカルのトランスクリプトファイル、リポジトリのログ、GitHub ツール、または貼り付けられた内容を使って成果物を特定します。要約よりも、最も直接的な情報源を優先します。
3. 成果物が実行中で、ユーザーが監視を求めている場合は、完了、ブロック、停滞、または人間／外部システムの対応待ちが明らかになるまで、適切な間隔で状態を確認します。
4. 成果物を特定できない場合は、不足している ID またはパスを尋ねます。

依頼内容を再構成する

作業を評価する前に、簡潔な依頼内容をまとめます。

• 元のユーザー依頼と、その後のスコープ変更。
• 明示的な制約：ブランチのルール、編集禁止の依頼、期限、パッケージのバージョン、検証要件、設計要件、セキュリティ／プライバシー上の制限など。
• 暗黙の受け入れ基準：ユーザーが目にする動作、テスト、CI、ドキュメント、デプロイ、スクリーンショット、レビューへの返信、ステータス更新など。
• もう一方のエージェントによる最終的な主張と、「実行できなかった」場合の注記。

もう一方のエージェントの要約ではなく、ユーザーの依頼を判断の基準とします。

独立して調査する

監視対象のエージェントを監査するのと並行して、元のプロンプトを自分にも与えられたものとして行動してください。アンカリングは失敗の原因です。つまり、相手の作業を先に読んで、うなずいてしまうことです。あなたの価値は、真に独立した二度目の検証から生まれます。

1. 根本原因について独自の仮説を立て、どのように進めるかを考えます。できれば監視対象のエージェントの結論を読む前に行い、すでに読んでいる場合も、相手の枠組みに引きずられず、第一原理から考えてください。
2. コード、データ、ログ、本番環境の状態、ドキュメントを、自分で直接またはサブエージェントを通じて調査します。監視対象のエージェントが作業中のあいだに、その時間を使って問題領域を事前に把握し、相手の差分が出る前に仮説を用意しておきます。
3. 監視対象のエージェントが調べていない可能性のある証拠を優先します。本番実行台帳やデータベース、セッションリプレイ、エラートラッカー、ユーザーから提供されたスクリーンショット、デプロイ／バージョンの状態、ほかのワークツリー、同じ領域で過去に発生したインシデントの記録などです。
4. 監視対象のエージェントの重要な主張を一次情報で検証し、自分で見つけた手掛かりも同じように検証します。どちらかが正しいと断言する前に、引用されたファイルと行番号を開き直してください。サブエージェントの報告は手掛かりであり、事実ではありません。
5. 二つの調査を比較します。相手が見つけて自分が見落としたこと、自分が見つけて相手が見落としたこと、アプローチが異なる点、暗黙のうちに選ばれたプロダクトや設計上の分岐を確認します。その比較を、具体的で実行可能な追加指示（正確なファイル、ガード、テストケース）に落とし込み、ユーザーがそのまま転送できるメモとして提示します。

伝達は必要最小限にする

何かを見つけたからといって、すぐに伝える必要はありません。監視対象のエージェントが作業中に受け取るメモのたびに、計画を練り直すことになります。伝達によるコストはトークンではなく、相手の注意と作業の順序です。

• 実行中の作業を中断するのは、現在の手順に影響する場合に限ります。相手が今まさに変更しているコードの欠陥、以前あなたが伝えた内容の訂正、または作業を妨げている質問への回答などです。
• それ以外のすべて（網羅性の不足、参考資料、慣例、仕上げの改善）は、次の確認時まで待ち、まとめて一度に伝えます。
• 実行中のエージェントに、優先順位のない不足項目リストを渡してはいけません。優先順位を付け、作業指示ではなく全体像として明示するか、伝えないでください。優先順位のないバックログを渡すと、複数の箇所が中途半端になる一方で、完成する箇所が少なくなりがちです。
• 問題点だけでなく、正しいと確認できた点も伝えてください。そうすることで、相手が解決済みの点を再検討せずに済み、対等な関係を保てます。
• 監視対象のエージェントが前回のメモにまだ対応していない場合、次のメモを送らないでください。

証拠を監査する

印象ではなく、証拠を調べてください。

• 変更されたファイルと、変更箇所周辺にある関連する未変更ファイルを読みます。
• 無関係な作業を元に戻さず、git status と差分を確認します。
• エージェントが実行したと主張するコマンドを、実際の出力が確認できる場合は照合します。
• 失敗またはスキップされたテスト、CI ログ、ブラウザーのスクリーンショット、レビューコメント、デプロイ出力、エラートレースを調べます。
• PR／レビュー作業では、ツールが使える場合、元のシステムで未解決のスレッドと CI の状態を確認します。
• UI 作業では、文章による説明よりスクリーンショットやブラウザーでの確認を優先します。

各問題を次のように分類します。

• 不足： 要求された動作が欠落している、または不完全です。
• バグ： 実装が動作しない、または既存の動作を損なう可能性があります。
• 検証不足： 作業自体は正しい可能性がありますが、根拠が不十分です。
• スコープ逸脱： 無関係な変更を加えた、または制約を無視しました。
• 問題なし： 懸念点はすでに対処されており、証拠で確認できます。

必要な箇所だけ修正する

ユーザーが修正を許可した場合：

1. 明確な根拠がある不備だけを修正します。
2. 無関係なローカル変更を保持し、ブランチ操作を明示的に依頼されない限り、ブランチを切り替えません。
3. 既存のリポジトリのパターンと対象を絞ったテストを使用します。
4. 意味のある修正を行うたびに、必要最小限の有効な検証を再実行します。
5. 修正に製品上の判断、認証情報、破壊的な操作、または広範な書き換えが必要な場合は、推測せずに作業を止め、判断を仰ぎます。

報告

結果を冒頭に記載します。内容をすばやく把握できるよう、報告は簡潔にまとめます。

Status
- Done, blocked, stale, or still running.

Requested
- What the user asked the watched agent to do.

Observed
- What the watched agent changed, claimed, and verified.

Gaps
- Missing behavior, bugs, weak verification, or scope drift.

Independent findings
- What your own investigation surfaced that the watched agent missed, where
  your approach would have differed, and concrete add-on directions to relay.

Fixes made
- Files changed and validation run. Omit this section for audit-only work.

Remaining risk
- Anything still unverified or waiting on CI/review/deploy/human input.

重要な場合は、正確なファイル名、コマンド、PR、スレッド ID を記載します。