| name | agent-review-request |
| description | 他エージェントへのレビュー依頼、実装結果の受け入れ検証、レビュー結果の妥当性確認を求められたときに使う。PRレビューコメント対応や通常のセルフレビューでは使わない。 |
Agent Review Request
生成したプロンプトを別のtmux paneのエージェントへ送信・監視・回収する場合、輸送手順は tmux-agent-bridge スキルに従う。
Overview
実装したエージェントとは別の目でレビューさせる、マルチエージェント運用の検証側ワークフロー。
実装者は自分の設計を正当化するバイアスを持つため、レビューは独立したエージェントに
「忖度なしのゼロベース評価」をさせることに価値がある。
3 つのモードがある。ユーザーの依頼がどれかを見極めて該当セクションだけ実行する:
- レビュー依頼プロンプト生成: 他エージェントに渡すレビュー用プロンプトを組み立てる
- 受け入れ検証: 自分がレビュー担当として、他エージェントの実装結果を検証し差し戻し指示を作る
- レビュー結果の解釈: 他エージェントから返ってきたレビュー結果の妥当性を判断する
Mode 1: レビュー依頼プロンプト生成
他エージェントの入力欄にそのまま貼れる形で、コードブロックで出力する。
定型ブロック(必ず含める)
対象リポジトリ: <絶対パス>
AGENTS.md / CLAUDE.md に従って、日本語でレビューしてください。
実装やファイルの変更は行わないでください。レビューのみです。
実装者の意図に忖度せず、ゼロベースで独立した評価をしてください。
- 「実装・変更禁止」の制約は省略しない。レビュー依頼を受けたエージェントは
善意で修正まで行いがちで、実装セッションと衝突して差分が壊れる事故につながる。
- レビュー対象外の既存差分がある場合は「既存の未コミット差分はユーザー承認済みの
作業差分として扱い、指摘対象にしない」を追加する。これがないと本題と無関係な
指摘でレビューが薄まる。
対象とスコープの指定
- 計画書があるとき(
agent-handoff-plan で引き継いだ実装のレビュー等):
計画書の絶対パスを渡し、2 段階でレビューさせる。
- スペック準拠レビュー: 計画書と実装 diff を突き合わせ、計画どおりか・
未実装フェーズはないか・「やらないこと」に手を出していないかを検証
- 品質レビュー: 計画から独立して、コードそのものの正しさ・設計・エッジケースを評価
- 計画書がないとき: レビュー範囲を明示的に絞る
(例: 「現在の未 push 差分を、Tailwind v4 移行に関わる部分に絞ってレビュー」)。
範囲指定のない全体レビュー依頼は焦点がぼけるので、背景(何をした変更か・何が不安か)を
1〜3 行で添える。
出力フォーマットの指定
指摘を差し戻しに使い回せるよう、レビュー側の報告形式も指定する:
指摘は次の形式で列挙してください:
- 重要度(must-fix / should-fix / nit)
- 対象ファイルと行
- 問題の内容
- 修正方針の提案
最後に総合判定(マージ可 / 修正後再レビュー / 設計から要見直し)を書いてください。
Mode 2: 受け入れ検証(差し戻しループ)
ユーザーが「実装が終わったらしいから確認して」「適切に行われているか評価して」と
依頼してきたときは、自分がレビュー担当になる。
- 計画書があれば Mode 1 と同じ 2 段階(スペック準拠 → 品質)で検証する。
計画書の DoD チェックリストを 1 項目ずつ実際に確認する(テストコマンドは実行する。
「書いてあるから通っているだろう」は禁止)。
- 検証結果は差し戻しに使える形でまとめる。ユーザーはこの結果をそのまま
実装エージェントに返すので、次の形式で出力する:
- 合格した項目(DoD のどれが満たされたか)
- 差し戻し項目: 項目ごとに「対象ファイル / 何が計画とずれているか・何が壊れているか /
期待される状態」を書く。実装エージェントがこのテキストだけで修正に着手できる粒度にする
- 総合判定: 受け入れ可 / 差し戻し(差し戻しの場合は、そのまま貼れる修正指示
プロンプトをコードブロックで添える)
- 自分では修正しない。修正まで行うと実装エージェント側の作業と衝突する。
ユーザーが明示的に「直しておいて」と言った場合のみ修正する。
Mode 3: レビュー結果の解釈
「こう評価されたけどどう思う?」と他エージェントのレビュー結果を渡されたときは、
鵜呑みにも反射的な反論にもならないように扱う:
- 指摘ごとに実際のコードを確認し、「妥当 / 誤検知 / 妥当だが優先度低」に仕分ける
- 誤検知と判断した指摘は、なぜそう判断したかの根拠(該当コードの実際の挙動)を示す
- 対応する場合の作業一覧を重要度順に提示する
他スキルとの関係
- 実装の引き継ぎ(計画書・ハンドオフプロンプト作成)は
agent-handoff-plan を使う
- GitHub PR のレビューコメント対応は
gh CLI で直接行う
- このスキルはローカルの差分・計画書ベースの独立レビューと差し戻しに特化する