review-loop

速さより質を優先したい作業で、一発目の出来をそのまま出したくないときに使います。本文の考え方は「最初の下書きは決して最終版ではない」の 1 行で、批評と直しを往復させるほうが 1 回で書くより良くなる、という前提です。

本文が挙げる場面は次のとおりです。

• 質を優先する実装速さより出来が大事な、込み入った実装
• 設計書・仕様・技術文書文章の成果物も対象
• 壊れては困るコード安全、データの流れ、金額の計算など
• 厳しい批評がほしい往復の中に辛口の批評を組み込みたいとき

呼び出しの合図として「use review-loop」「polish this」「iterate on this」「/review-loop」などの言い回しが説明文に並んでいます。

往復の仕組み

1. 作るふだんどおりに最善の一発目を作る（既存の成果物を読むだけの場合もある）
2. 採点役を起こす別のサブエージェントに、成果物だけを渡して 1〜10 で採点させる
3. 指摘を読む点数と、重大・重要・軽微に分けた指摘を取り出し、回ごとに報告する
4. 止めるか決める最低回数・合格点・最大回数の順に判定する
5. 直す重大と重要を直し、軽微は任意。指摘された所だけを狙って直す
6. 仕上げ残った軽微な点を片付け、直しの跡が残っていないかを見て、最終の点数と回数を報告する

既定の値

最低の往復の回数

2 回

最大の往復の回数

4 回

合格点

8 / 10

止める判定は順番が決まっています。最低回数に届いていなければ必ず続ける。合格点に届いたら仕上げへ。最大回数に届いたら合格点に届かなくても仕上げへ。どれでもなければ直してもう 1 回です。

依頼の言葉で値を変えられる

「quality gate 9」「max 5 loops」「min 3」のように依頼の中で書けば、その値が使われます。「thorough」「strict」は合格点 8・最低 2 回、「quick」「fast」は最大 2 回・合格点 6 として読む、という決まりもあります。

採点役への頼み方

採点役は会話を引き継がない別のサブエージェントで、渡すのは成果物（ファイルや差分）だけです。作り手の考えの筋道を渡すと、採点役がそれに引きずられるからです。

依頼の雛形には、点数の帯（1〜3 は根本から壊れている、4〜6 は動くが大きな問題、7〜8 は軽微な問題だけ、9〜10 は出荷できる）、ファイルと行を添えた指摘、なぜ大事かと何を直すか、「礼儀正しくするな」、最後に「Score: N/10」と書くこと、が入っています。

作業の種類ごとの観点

本文の表は、作業の種類ごとに採点役が見るべきところを 9 種類挙げています。たとえばコードなら正しさ・端の場合・エラー処理・読みやすさ・安全の問題が無いこと、データベースの移行なら戻せるか・索引の方針・データを失う危険・規模での性能です。

本文の「使わないとき」は 5 つです。

• 小さな修正1 行の変更や手早い編集
• 試験が合否を決める作業試験を先に書く進め方と CI に任せる
• とにかく早く終わらせたい往復の分だけ時間がかかる
• 探りの作業目的が出荷ではなく学ぶこと
• 受け入れの条件が無い先に条件を決めてから使う

人のレビューの代わりにはしない

本文の「分かっている限界」に、安全や法令に関わるコードでは人のレビューの代わりにならず、強めの一次点検として扱え、と書かれています。

別のエージェントにレビューを出すだけなら

1 回だけ別のエージェントに見てもらえば足りるなら、点数の往復は要りません。obra の requesting-code-review は、組み立てた文脈だけを渡してレビューを出させる型です。計画を作業ごとに別のエージェントへ渡し、毎回レビューを通させる進め方なら subagent-driven-development があります。レビューの観点を「規約」と「仕様」に分けたいなら、mattpocock の code-review が別にあります。

SKILL.md には、外部への通信やシェルの実行の記述はありません。直しの段で成果物のファイルを書き換えます。

同梱ファイルは 0 件で、SKILL.md は 12,522 バイトです（2026-10-22 時点）。

採点役は作り手と同等以上に

本文が「決定的な規則」と呼ぶのが、採点役の能力を作り手と同等以上にすることです。弱い採点役では込み入った論理や見えにくい後退を見つけられない、という理由です。

作業の難しさごとの組み合わせの表もあります。単純な作業なら軽い作り手と中くらいの採点役、安全や分散の仕組みのような難しい作業なら両方とも推論の強いもの、という具合です。

同じ指摘で点が上がらないとき

同じ指摘のまま 2 回続けて点が上がらないなら、作り手の能力が足りない印だとされています。その場合の手は 3 つで、より強いモデルへの切り替えを利用者に頼む、合格点を一時的に下げて差を伝える、作業を小さく割ってそれぞれで往復させる、です。

採点役は前の回を覚えていない

採点役には前の回の記憶が無いので、すでに直した点を繰り返し指摘させないよう、前の指摘を毎回の依頼に含めよ、と書かれています。基準があいまいだと点数が甘くなりやすいので、具体的で測れる基準を書くことにも時間をかけよ、とあります。

やってはいけないこと

自分で自分を採点すること、根拠無しに指摘を無視すること、自分の点を水増しすること、利用者の同意なしに最大回数を超えること、採点役に考えの筋道を渡すこと、の 5 つです。採点役が間違っているときは、コードや試験で反証を示し、その点だけ直しを飛ばし、利用者への報告に書く。合格の基準を下げて埋め合わせない、と決められています。

ライセンスの表記

SKILL.md の末尾に MIT と書かれています。リポジトリに LICENSE のファイルはありません（2026-10-22 確認）。

サブエージェントが使えない環境でも動きますか

本文に代わりの手順があります。新しい会話を開き、考えの筋道は貼らずに成果物だけを貼って、1〜10 の点数と具体的な指摘を求めます。最もよく動くのはサブエージェントを起動できる環境だ、と本文は書いています。

すでに書いたコードにも使えますか

使えます。本文には 2 つの使い方があり、作るところから往復させる形と、既存の成果物を読んで往復だけを回す形です。後者は「さっき書いた認証モジュールに review-loop をかけて」のように頼みます。

点数が 8 に届かないまま終わることはありますか

あります。最大回数に届いたら、合格点に届いていなくても仕上げに進んで止まります。最大回数を超えて続けるには利用者の同意が要る、と決められています。

対応しているエージェントはどれですか

当サイトでは「記載なし」として扱っています。公開元の README は、サブエージェントを起動できるエージェントの例として「Cursor、Claude、Windsurf」を挙げていますが、Claude Code と特定した書き方ではありません（2026-10-22 確認）。SKILL.md の手順は採点役を起こす道具を「Agent tool」と呼んでいます。