review-loop

レビューループ

1つのセッション内で、作業者とレビュアーが反復して作業するサイクルです。作業を行い、レビュアーのサブエージェントを起動して批評を受け、フィードバックに基づいて修正し、品質ゲートを満たすまで繰り返します。

基本原則： 初稿を最終版にすることはありません。反復的な批評により、1回だけの作業よりも優れた成果を得られます。

プラットフォームに関する注意： このスキルは、サブエージェントの起動に対応したエージェントで最も効果を発揮します。 対応していないプラットフォームでは、新しいチャットコンテキストを開き、 作成物だけ（それまでの推論は含めず）を貼り付けて、具体的なフィードバックとともに 1～10で評価するよう依頼し、レビュアーの手順を再現してください。

クイックスタート

1. "implement X, use review-loop" または "run review-loop on the file I just wrote" と入力します
2. エージェントが作業を行います（または既存の作成物を読み込みます）
3. 独立した批評サブエージェントが、具体的なフィードバックとともに1～10で評価します
4. エージェントがスコアが8以上（デフォルトの品質ゲート）になるまで修正を繰り返します
5. 最終成果物とともに、ループの概要が提示されます

---

使用する場面

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

使用しない場面

• 単純な修正、手早い編集、1行だけの変更
• テストが品質ゲートとなるタスク（代わりにTDD＋CIを使用してください）
• ユーザーがとにかく早く仕上げることを望んでいる場合
• 目的がリリースではなく学習である、探索的な作業や試験的な作業
• 明確な受け入れ基準がないタスク — まず基準を定義してから、レビューループを使用してください

---

デフォルト設定

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

---

モデルの選択

レビュアーのタスクではロジックと制約を評価します。作業者のタスクではコードを作成・変更します。それぞれに適したサブエージェントの能力を選択してください。

重要なルール： レビュアーの能力は、必ず作業者と同等以上でなければなりません。レビュアーの能力が作業者より低いと、複雑なロジックを適切に批評したり、微妙なリグレッションを検出したりできません。

タスクの複雑さ	作業者の能力	レビュアーの能力	理由
単純／機械的（CRUD、書式設定、定型コード）	高速／軽量	バランス型	軽量な作業者は高速で、バランス型のレビュアーは問題を容易に検出できます
標準（機能、リファクタリング、ドキュメント）	バランス型	バランス型	コスト、速度、品質のバランスに優れています
複雑（複数ファイル、統合、設計）	バランス型	高度／推論型	高度なレビュアーは微妙なアーキテクチャ上の問題を検出でき、バランス型の作業者はそれを実装できます
非常に複雑（セキュリティ、定量分析、分散システム）	高度／推論型	高度／推論型	どちらにも十分な文脈理解と推論能力が必要です。レビュアーの能力は作業者と同等でなければなりません。

最も重要なルール： 作業者には、レビュアーのフィードバックを理解して対応できる能力が必要です。レビュアーが「チャネルベースのセマフォで競合状態を修正してください」と指摘しても、作業者に並行処理を推論する能力がなければ、ループは収束しません。

エスカレーションの兆候： 同じフィードバックが続き、2回連続でスコアが改善しない場合は、作業者モデルの能力が不足しています。次のようにエスカレーションしてください。

• オプションA：より高性能なモデルに切り替えるようユーザーに依頼します
• オプションB：一時的に品質ゲートを引き下げ、ユーザーに不足点を伝えます
• オプションC：タスクを小さなサブタスクに分割し、それぞれにレビューループを実行します

デフォルトの動作： メインエージェントであるあなた自身が作業者となるため、タスクに応じて、現在の能力と同等以上のレビュアーサブエージェントを起動してください。

• ほとんどのタスク → 標準／バランス型レビュアー
• 専門的／難しいタスク → 高度／推論型レビュアー
• 簡単な確認 → 高速／軽量レビュアー（あなた自身も軽量な作業者として動作する場合に限る）

---

ユーザーによる上書き

ユーザーはリクエスト内で、任意のデフォルト設定を上書きできます。次のように自然に解釈してください。

"implement X with review-loop, quality gate 9, use advanced model for review, max 5 loops"
"polish this, 2 loops minimum, gate at 8"
"run review-loop with fast reviewer, max 2 loops"
"use review-loop, reasoning reviewer, quality gate 9, min 3 max 6"

解釈ルール：

• 「quality gate N」または「gate N」→ quality_gate = N
• 「[model] reviewer」または「review with [model]」→ レビュアーモデルを上書き
• 「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[Do the work] --> B[Spawn reviewer subagent]
    B --> C{Min loops met?}
    C -- no, always continue --> E[Revise based on feedback]
    C -- yes --> D{Score >= quality gate?}
    D -- yes --> F[Final polish pass]
    D -- no --> G{Max loops reached?}
    G -- yes, stop anyway --> F
    G -- no --> E
    E --> B
    F --> H([Done])

---

手順

ステップ 1：作業する

通常どおりタスクを完了します。コードを書き、仕様を作成し、機能を実装します。出し惜しみせず、最善の初稿を作成してください。

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

Agent ツールを使ってレビュアーを割り当てます。レビュアーは次の条件を満たす必要があります。

• 独立したサブエージェントである（新しいコンテキストを持ち、あなたの推論に引きずられない）
• 成果物（ファイル、差分）のみを受け取る。あなたの思考プロセスは受け取らない
• 具体的で実行可能なフィードバックとともに、1〜10 のスコアを付ける
• デフォルトではバランスの取れた標準モデルを使用する（複雑または専門的なタスクでは高度な推論モデルを使用する）

レビュアー向けプロンプトのテンプレート：

You are a critical reviewer. Score the following work 1-10 and provide specific, actionable feedback.

## What was done
{brief description of the task}

## Review criteria
{task-specific criteria — what matters for THIS task}

Examples of well-written criteria:
  For a REST API endpoint:
    - Correct HTTP status codes used
    - Input validation present on all parameters
    - Auth enforced; no unauthenticated access
    - No N+1 query patterns

  For a design doc:
    - Problem statement is unambiguous
    - Alternatives considered with trade-offs
    - No hand-waving on implementation complexity
    - Success metrics are measurable

  For a data pipeline:
    - Idempotent — safe to re-run
    - Schema changes handled gracefully
    - Failure modes documented
    - PII handling addressed

## Instructions
1. Read the work carefully
2. Score 1-10 where:
   - 1-3: Fundamentally broken or missing major requirements
   - 4-6: Works but has significant issues
   - 7-8: Good, minor issues only
   - 9-10: Excellent, ready to ship
3. List specific issues with file:line references where applicable
4. For each issue, explain WHY it matters and WHAT to fix
5. Do NOT be polite — be honest and direct
6. State your score clearly as "Score: N/10"

## Files to review
{paste file contents or list file paths with relevant excerpts}

ステップ 3：フィードバックを解釈する

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

• スコア（数値）
• 問題点（Critical／Important／Minor に分類）
• 具体的な修正点（変更すべき内容）

ユーザーに次の内容を報告します。

Loop {N}/{max}: Score {X}/10
- {summary of key feedback points}

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

次の順序で確認します。

1. 完了したループ数 < min_loops の場合 → 必ず続行
2. スコア >= quality_gate の場合 → 停止して、最終仕上げに進む
3. 完了したループ数 >= max_loops の場合 → 停止して、最終仕上げに進む
4. それ以外の場合 → 修正してループを続ける

ステップ 5：修正する

レビュアーのフィードバックに対応します。Critical と Important の問題を修正します。Minor の問題は任意です。その後、ステップ 2 に戻ります。

重要： 各修正は対象を絞って行ってください。すべてを書き直すのではなく、レビュアーが指摘した点を修正します。以前のフィードバックをすべて把握し、後戻りを避けてください。

ステップ 6：最終仕上げ

ループを終了したら（品質ゲートを満たした場合、または最大ループ数に達した場合）：

• 残っている Minor の問題が簡単に修正できる場合は対応します
• 最終出力に一貫性があることを確認します（修正サイクルの痕跡が残っていないこと）
• 最終スコアとループ回数をユーザーに報告します

---

タスクの種類に応じたレビュアーの評価基準

タスクの種類	レビュアーが重視すべき点
コード	正確性、エッジケース、エラー処理、可読性、セキュリティ上の問題がないこと
仕様／設計	完全性、実現可能性、曖昧な説明がないこと、実装可能性
リファクタリング	振る舞いの変更がないこと、リグレッションがないこと、以前より整理されていること
文章作成	明瞭さ、構成、対象読者への適切さ、無駄がないこと
バグ修正	根本原因への対処、リグレッションテストの存在、副作用がないこと
インフラストラクチャ／IaC	冪等性、最小権限、ハードコードされたシークレットがないこと、安全に破棄できること
データベースのマイグレーション	可逆性、インデックス戦略、データ損失のリスク、大規模運用時のパフォーマンス
API 設計	下位互換性、認証、バージョニング、エラー契約
テストスイート	エッジケースの網羅性、テスト間の依存がないこと、有意義なアサーション

---

2 つの動作モード

モード A：「実行してレビュー」（完全なサイクル）

ユーザーがタスクを提示し、review-loop を使うよう指示します。作業を行い、レビューのループも実行します。

User: "Implement the caching layer. Use review-loop, quality gate 8."

You:
1. Implement caching layer
2. Spawn reviewer → Score 6, feedback: missing eviction, no TTL
3. Revise: add eviction + TTL
4. Spawn reviewer → Score 8, feedback: minor naming nit
5. Final polish, done

モード B：「既存の成果物をレビュー」（レビューのみ）

ユーザーがすでに作業を完了しているか、あなたがすでに作業を完了しています。既存の成果物に対してレビューのループのみを実行します。

User: "Run review-loop on the auth module I just wrote"

You:
1. Read the auth module
2. Spawn reviewer → Score 5, feedback: SQL injection, no rate limiting
3. Fix: parameterize queries, add rate limiter
4. Spawn reviewer → Score 8, approved
5. Done

---

危険信号

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

• サブエージェントを起動せず、自分でレビューする（アンカリングバイアス）
• 「フィードバックが間違っている」という理由だけで、根拠を示さずに修正サイクルを省略する
• 自分のスコアを水増しする（「実際は9点だと思う」）
• ユーザーの同意なく、max_loops を超えて続ける
• レビュアーに自分の推論や経緯をすべて渡して起動する（レビュアーは意図ではなく、成果物をレビューする必要があります）

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

• 根拠を示して反論する（フィードバックに反するコードやテストを提示する）
• 修正時に、その特定の指摘はスキップする
• ユーザーへの報告にその旨を記載する
• 埋め合わせのために、品質基準を下げてはいけない

---

レポート形式の例

--- Review Loop: {task name} ---

Loop 1/4: Score 6/10
  Reviewer: Missing input validation, no error handling for network timeout,
            function too long (80 lines).
  Action: Fixing all three issues.

Loop 2/4: Score 8/10
  Reviewer: Clean. Minor: variable name `d` could be more descriptive.
  Action: Quality gate met (8 >= 8). Final polish.

Result: 8/10 in 2 loops. Done.

---

既知の制限事項

• レビュアーのサブエージェントは前のループの内容を記憶していません。解決済みの問題が繰り返し指摘されないよう、各レビュアー用プロンプトに過去のフィードバックの文脈を明記してください
• レビュアー用プロンプトの基準が曖昧だと、スコアが水増しされる可能性があります。具体的で測定可能な基準を書くことに時間をかけてください
• このスキルは、セキュリティ上重要なコードやコンプライアンスに関わるコードの人間によるコードレビューの代わりにはなりません。成果物は、質の高い初回レビューとして扱ってください
• タスクの仕様が不十分な場合、ループが収束するとは限りません。開始前に、明確な受け入れ基準を定めてください

---

コストと速度

• ループ1回につき、レビュアーのサブエージェント呼び出しが1回発生します
• 3ループのサイクル全体では、実装を1回行う時間のおよそ1～2倍を見込んでください
• これは、バグのあるコードや曖昧な仕様を公開したり、後半のレビューサイクルを招いたりするコストと比べれば安価です
• ほとんどのレビューでは、標準のモデルを使用してください。高度な推論モデルに切り替えるのは、専門分野（セキュリティ監査、分散システム、クオンツ金融）に限ります

---

ライセンス

MIT — あらゆる AI ツールやプラットフォームで、自由に使用、改変、再配布できます。クレジット表記を歓迎します。コントリビューションも歓迎します。