レビューループ

単一セッション内で反復的なワーカー・レビュアーサイクルを実行します。あなたが作業を行い、レビュアーサブエージェントを起動して批評を受け、フィードバックに基づいて修正し、品質ゲートを満たすまで繰り返します。

核となる原則: 初稿は決して最終版ではありません。反復的な批評により、1回のパスよりも優れた出力が得られます。

プラットフォームに関する注意: このスキルは、サブエージェントのスポーンをサポートするエージェントで最も効果的に機能します。その機能がないプラットフォームでは、新しいチャットコンテキストを開き、作業成果物のみ（以前の推論は含めない）を貼り付け、1〜10のスコアと具体的なフィードバックを依頼することで、レビュアーステップをシミュレートできます。

クイックスタート

「Xを実装して、review-loopを使用」または「今書いたファイルに対してreview-loopを実行」と指示します。
エージェントが作業を行います（または既存の作業を読み取ります）。
別の批評家サブエージェントが1〜10のスコアと具体的なフィードバックを返します。
エージェントは修正し、スコアが8以上（デフォルトの品質ゲート）になるまで繰り返します。
ループサマリーと最終出力が提供されます。

使用すべき場合

ユーザーが「review-loopを使用」、「これを磨き上げて」、「これを反復して」、「/review-loop」と指示した場合
品質が速度よりも重要な複雑な実装
設計ドキュメント、仕様書、技術文書
堅牢性が求められるコード（セキュリティ、データパイプライン、金融ロジック）
ユーザーがプロセスに敵対的な批評を組み込みたい場合

使用すべきでない場合

単純な修正、簡単な編集、1行の変更
テストが品質ゲートとなるタスク（代わりにTDD + CIを使用）
ユーザーが単に高速な完了を望んでいる場合
探索的・スパイク的な作業（目標が学習であり、リリースではない場合）
明確な受け入れ基準がないタスク — まず基準を定義し、その後でreview-loopを使用

デフォルト設定

設定	デフォルト
最小ループ回数	2
最大ループ回数	4
品質ゲート	8/10
ワーカーモデル	（現在のモデル）
レビュアーモデル	（現在のモデル、または高速／バランスの取れた代替モデル）

モデル選択

レビュアーのタスクはロジックと制約を評価します。ワーカーのタスクはコードを作成・修正します。それに応じてサブエージェントの能力を選択してください。

重要なルール: レビュアーは常にワーカーと同等か、それ以上に強力でなければなりません。レビュアーがワーカーよりも弱い場合、複雑なロジックを適切に批評したり、微妙な退行を発見したりできません。

タスクの複雑さ	ワーカーの能力	レビュアーの能力	根拠
単純／機械的（CRUD、フォーマット、ボイラープレート）	高速／軽量	バランス型	軽量ワーカーは高速、バランス型レビュアーは問題を容易に発見
標準（機能、リファクタリング、ドキュメント）	バランス型	バランス型	コスト、速度、品質の良いバランス
複雑（複数ファイル、統合、設計）	バランス型	先進／推論型	先進レビュアーは微妙なアーキテクチャ問題を発見、バランス型ワーカーは実装可能
非常に複雑（セキュリティ、定量、分散システム）	先進／推論型	先進／推論型	両方に完全なコンテキストと推論能力が必要。レビュアーはワーカーと同等の能力でなければならない

黄金律: ワーカーはレビュアーのフィードバックに基づいて行動できるほど賢くなければなりません。レビュアーが「チャネルベースのセマフォで競合状態を修正せよ」と指摘し、ワーカーが並行性について推論できない場合、ループは収束しません。

エスカレーションシグナル: 同じフィードバックで2回連続してスコアが改善しない場合、ワーカーモデルが弱すぎます。エスカレーションしてください：

オプションA：ユーザーに、より高性能なモデルに切り替えるよう依頼する
オプションB：一時的に品質ゲートを下げ、その差異をユーザーに通知する
オプションC：タスクをより小さなサブタスクに分割し、それぞれにreview-loopを実行する

デフォルトの動作: あなた（メインエージェント）がワーカーですので、タスクに基づいて現在の能力に匹敵するかそれを上回るレビュアーサブエージェントを起動してください：

ほとんどのタスク → 標準／バランス型レビュアー
専門的／難しいタスク → 先進／推論型レビュアー
クイックチェック → 高速／軽量レビュアー（あなた自身も軽量ワーカーとして行動している場合のみ）

ユーザーによる上書き

ユーザーはリクエスト内で任意のデフォルトをインラインで上書きできます。これらを自然に解析してください：

「Xを実装して、review-loop、品質ゲート9、レビューには先進モデルを使用、最大5ループ」
「これを磨き上げて、最小2ループ、ゲートは8」
「高速レビュアーでreview-loopを実行、最大2ループ」
「review-loopを使用、推論型レビュアー、品質ゲート9、最小3最大6」

解析ルール:

「quality gate N」または「gate N」 → quality_gate = N
「[モデル名] reviewer」または「review with [モデル名]」 → レビュアーモデルの上書き
「max N loops」 → max_loops = N
「min N loops」 → min_loops = N
ユーザーが指定しない場合はデフォルトを使用
ユーザーが「thorough」または「strict」と言った場合 → quality_gate 8、min_loops 2 と解釈
ユーザーが「quick」または「fast」と言った場合 → max_loops 2、quality_gate 6 と解釈

プロセス

flowchart TD
    A[作業を実行] --> B[レビュアーサブエージェントを起動]
    B --> C{最小ループ回数に達した？}
    C -- いいえ、常に継続 --> E[フィードバックに基づいて修正]
    C -- はい --> D{スコア >= 品質ゲート？}
    D -- はい --> F[最終ポリッシュパス]
    D -- いいえ --> G{最大ループ回数に達した？}
    G -- はい、そこで停止 --> F
    G -- いいえ --> E
    E --> B
    F --> H([完了])

ステップバイステップ

ステップ 1: 作業を実行する

通常通りタスクを完了します。コードを書き、仕様を作成し、機能を実装します。ためらわずに、最善の初回着手を生成してください。

ステップ 2: レビュアーサブエージェントを起動する

エージェントツールを使用してレビュアーを派遣します。レビュアーは以下の条件を満たす必要があります：

別のサブエージェントであること（新しいコンテキスト、あなたの推論に引きずられない）
作業成果物（ファイル、差分）のみを受け取ること — あなたの思考プロセスは受け取らない
1〜10のスコアと具体的で実用的なフィードバックを提供すること
デフォルトではバランス型／標準モデルを使用すること（複雑／専門的なタスクには先進推論モデルを使用）

レビュアープロンプトテンプレート:

あなたは批評家です。以下の作業を1〜10で評価し、具体的で実用的なフィードバックを提供してください。

## 行われた作業
{タスクの簡単な説明}

## レビュー基準
{タスク固有の基準 — このタスクで重要なこと}

適切に書かれた基準の例：
  REST APIエンドポイントの場合：
    - 正しいHTTPステータスコードが使用されている
    - すべてのパラメータに入力検証が存在する
    - 認証が適用されている。認証されていないアクセスがない
    - N+1クエリパターンがない

  設計ドキュメントの場合：
    - 問題の記述が曖昧でない
    - 代替案がトレードオフとともに検討されている
    - 実装の複雑さについてごまかしていない
    - 成功指標が測定可能である

  データパイプラインの場合：
    - べき等性がある — 再実行しても安全
    - スキーマ変更を適切に処理している
    - 障害モードが文書化されている
    - PIIの取り扱いが対処されている

## 指示
1. 作業を注意深く読んでください
2. 1〜10で評価してください。ただし：
   - 1〜3：根本的に壊れているか、主要な要件が欠落している
   - 4〜6：機能するが、重大な問題がある
   - 7〜8：良好、軽微な問題のみ
   - 9〜10：優れており、リリース準備完了
3. 該当する場合はファイル:行番号を参照して具体的な問題を列挙してください
4. 各問題について、**なぜそれが重要か**、**何を修正すべきか**を説明してください
5. 丁寧であろうとしないでください — 正直かつ直接的であること
6. スコアを「Score: N/10」として明確に記載してください

## レビューするファイル
{ファイルの内容を貼り付けるか、ファイルパスと関連する抜粋をリストアップ}

ステップ 3: フィードバックを解析する

レビュアーの応答から以下を抽出します：

スコア（数値）
問題（重大／重要／軽微に分類）
具体的な修正（何を変更すべきか）

ユーザーに報告します：

ループ {N}/{最大}: スコア {X}/10
- {主要なフィードバックポイントの概要}

ステップ 4: 停止条件を確認する

この順序で：

ループ回数が最小ループ回数未満の場合 → 継続（常に）
スコアが品質ゲート以上の場合 → 停止、最終ポリッシュへ
ループ回数が最大ループ回数以上の場合 → 停止、最終ポリッシュへ
それ以外の場合 → 修正してループ

ステップ 5: 修正する

レビュアーのフィードバックに対処します。重大および重要な問題を修正します。軽微な問題は任意です。その後、ステップ 2 に戻ります。

重要: 各修正は的を絞って行ってください。すべてを書き直さず、レビュアーが指摘した箇所を修正します。これまでのすべてのフィードバックを頭の中で保持し、退行を防いでください。

ステップ 6: 最終ポリッシュ

ループが終了したら（品質ゲートを満たしたか、最大ループ回数に達した）：

残っている軽微な問題があれば、簡単に対処します
最終出力に一貫性があることを確認します（修正サイクルによるアーティファクトがないこと）
最終スコアとループ回数をユーザーに報告します

タスクタイプ別のレビュー基準の適応

タスクタイプ	レビュアーが焦点を当てるべき点
コード	正確性、エッジケース、エラー処理、可読性、セキュリティ問題の不在
仕様／設計	完全性、実現可能性、ごまかしの不在、実装可能性
リファクタリング	動作変更の不在、退行の不在、以前よりクリーンであること
文書作成	明確さ、構造、対象読者に適切、冗長でないこと
バグ修正	根本原因に対処、退行テストの存在、副作用の不在
インフラ／IaC	べき等性、最小特権、ハードコードされたシークレットの不在、破棄の安全性
データベース移行	可逆性、インデックス戦略、データ損失リスク、スケール時のパフォーマンス
API設計	後方互換性、認証、バージョニング、エラー契約
テストスイート	エッジケースのカバレッジ、テスト間の依存関係の不在、意味のあるアサーション

2つの動作モード

モード A: 「実行してレビュー」（フルサイクル）

ユーザーがタスクを与え、review-loopを使用するよう指示します。あなたが作業を行い、レビューループも実行します。

ユーザー: 「キャッシュレイヤーを実装して。review-loop、品質ゲート8で。」

あなた:
1. キャッシュレイヤーを実装
2. レビュアーを起動 → スコア6、フィードバック：削除ポリシー欠落、TTLなし
3. 修正：削除ポリシー + TTLを追加
4. レビュアーを起動 → スコア8、フィードバック：軽微な命名の問題
5. 最終ポリッシュ、完了

モード B: 「既存のものをレビュー」（レビューのみ）

ユーザーがすでに作業を行ったか、あなたがすでに作業を行いました。単に既存のものに対してレビューループを実行します。

ユーザー: 「今書いたauthモジュールに対してreview-loopを実行して」

あなた:
1. authモジュールを読み込む
2. レビュアーを起動 → スコア5、フィードバック：SQLインジェクション、レート制限なし
3. 修正：クエリをパラメータ化、レートリミッターを追加
4. レビュアーを起動 → スコア8、承認
5. 完了

レッドフラグ

絶対にしてはいけないこと:

サブエージェントを起動せずに自己レビューすること（アンカリングバイアス）
正当な理由なく「フィードバックが間違っている」として修正サイクルをスキップすること
自分のスコアを水増しすること（「これは実際には9だと思う」）
ユーザーの同意なしに最大ループ回数を超えて継続すること
完全な推論や履歴をレビュアーに渡すこと（レビュアーは作業をレビューすべきであり、意図ではない）

レビュアーが間違っている場合:

証拠（フィードバックを反証するコード／テスト）を示して反論する
修正時にその特定のポイントをスキップする
ユーザーへのレポートにその旨を記載する
品質基準を下げて補償しない

レポート形式の例

--- レビューループ: {タスク名} ---

ループ 1/4: スコア 6/10
  レビュアー: 入力検証欠落、ネットワークタイムアウトのエラー処理なし、
            関数が長すぎる（80行）。
  アクション: 3つの問題すべてを修正中。

ループ 2/4: スコア 8/10
  レビュアー: クリーン。軽微：変数名 `d` はより説明的にするべき。
  アクション: 品質ゲートを満たしました（8 >= 8）。最終ポリッシュ。

結果: 2ループで 8/10。完了。

既知の制限事項

レビュアーサブエージェントは以前のループの記憶を持ちません — 解決済みの問題を繰り返さないように、各レビュアープロンプトに以前のフィードバックのコンテキストを明示的に含めてください
レビュアープロンプトの基準が不明確すぎると、スコアの水増しが発生する可能性があります — 具体的で測定可能な基準を記述することに時間をかけてください
このスキルは、セキュリティ上重要またはコンプライアンスが求められるコードに対する人間によるコードレビューの代替にはなりません — 出力を強力な初回パスとして扱ってください
タスクの仕様が不十分な場合、ループの収束は保証されません — 開始前に明確な受け入れ基準を定義してください

コストと速度

各ループ = 1回のレビュアーサブエージェント呼び出し
フル3ループサイクルの場合、単一実装パスの約1〜2倍の時間を見積もってください
これは、バグのあるコード、曖昧な仕様の出荷、または後期のレビューサイクルを引き起こすことと比較すると安価です
ほとんどのレビューにはデフォルト／標準モデルを使用してください。専門分野（セキュリティ監査、分散システム、定量ファイナンス）にのみ、先進推論モデルにアップグレードしてください

ライセンス

MIT — 自由に使用、改変、再配布できます。クレジット表記をお願いします。コントリビューションを歓迎します。

2dmurali/review-loop

review-loop とは？

お気に入りのAIに質問する

ドキュメント