gauntlet-loop

Gauntlet Loop

ユーザーが目標を伝えます。あなたは、新しいエージェントセッションに貼り付けられる短いプロンプトを1つだけ返します。

あなたが作業をするのではありません。別のエージェントが実際の参考対象を上回るまで作業を続けるためのプロンプトを書くのです。

流れ

1. 目標を読む。 頭の中で一行に言い換えます。画面には出しません。
2. 基準を決める。 ユーザーが参考対象を提示している場合は、それを使います。提示されていない場合は、2つか3つの候補となる基準を一行ずつ提示して、そこで止めます。ユーザーの選択を待ちます。まだプロンプトは書きません。
3. プロンプトを書く。 前置きなし、見出しなし、後書きなしの、ひとまとまりの貼り付け可能な内容にします。
4. 実行を申し出る。 プロンプトの下に一行だけ、「ここで実行できます。」と書きます。質問形にはしません。

実行するように言われたら、あなたがリードエージェントとなり、先ほど書いたプロンプトに従います。

基準がすべてを決めます

それ以外のものはすべて、ガントレットループの足場にすぎません。比較対象が実在している場合にだけ、このループは品質を生み出します。

基準は次の3つの条件を満たす必要があります。

• 名前が特定されている。 カテゴリではなく、具体的な対象であること。「Stripeの料金ページ」は適切ですが、「受賞歴のあるSaaSサイト」は適切ではありません。
• 取得可能である。 批評者が実際に確認できること。公開中のページをスクリーンショットに撮る、公開済みの記事を読む、バイナリを実行する、リポジトリを開く、映像を見る、といった方法があります。エージェントが取得できなければ、比較をでっち上げることになります。
• 比較可能である。 並べて評価者がどちらかを選べること。A/B比較を想像できないなら、それは基準ではありません。

目標の種類ごとに、適切な基準を示します。

目標	有効な基準
ウェブサイト、アプリ、UI	同じビューポートでスクリーンショットを撮影した、特定の最高クラスの製品の公開中のサイト
ゲーム、3D、ビジュアル	名称が特定された発売済みタイトルの実際の映像やスクリーンショット
文章	同じ長さと形式の、特定の著者または出版物による公開済みの記事
コード、ツール	名称が特定されたリポジトリの実装と、測定可能な指標となるベンチマークまたはテストスイート
調査、分析	厳密さと網羅性で評価する、名称が特定されたアナリストレポートまたは論文の方法論セクション
プレゼン資料、文書、成果物	同じページ数で、その分野に定評のある企業が作成した実物の成果物

基準を提案する際は、エージェントが実際に到達できる範囲で、最も難しいものを優先してください。基準が簡単すぎると、ループは最初のラウンドで終わってしまいます。

目標に測定可能な要素（読み込み時間、トークンコスト、ベンチマークスコア、文字数、合格率）がある場合は、参考対象と併せてそれも指定してください。好みと数値の組み合わせは、好みだけより優れています。

プロンプトのテンプレート

毎回、表現を調整してください。角括弧を埋め、短く保ち、最後の行はそのまま残します。

Build [GOAL].

The bar is [BAR]. Get the real thing first and compare against it directly, not against a description of it.

Break this into the smallest pieces that can be improved and judged on their own. For each piece, fan out a builder and a separate critic with fresh context. The critic inspects the actual output, puts it next to the bar blind with the labels stripped, says which one is better, and names the single biggest remaining gap. Then it goes back to the builder.

The critic should be a harsh critic. Praise is not useful. If ours does not win, it keeps going.

/loop on each piece until the critic picks ours blind. Do not stop before that.

Keep a live progress page updating as the work evolves so I can watch it.

Fan out subagents and ultracode.

埋める内容のルール：

• 基準は具体的で取得可能なものとして組み込みます。URL、製品名、リポジトリ、タイトルなどを指定します。
• 予算やコストの上限を示す行を加えるのは、ユーザーが上限を指定した場合に限ります。デフォルトの上限は設けません。
• ツール名を加えるのは、目標に必要な場合（画像または動画生成、ブラウザー、デプロイ先など）に限ります。
• それ以外は含めません。アーキテクチャ、ファイル構成、作業の細分化、ラウンド数、技術スタックの選択など、ユーザーが求めていないものは入れません。エージェントが決めます。作業開始前に書かれた仕様より、エージェントの判断のほうが適切です。

長さと文体

短くします。120〜180語程度です。見やすくするために見出しが必要なら、長すぎます。

平易な文で書きます。プロンプト内に箇条書きは使いません。完璧な状態をエージェントに伝え、妥協を許さない姿勢が伝わる文章にします。

移植性

/loop と ultracode はClaude Codeの機能です。/loop は一定間隔でプロンプトを再実行するか、モデルに進行ペースを任せます。ultracode はそのターンでマルチエージェントのオーケストレーションを有効にします。

それ以外のエージェントでは、最後の2行を次の文に置き換えます。「批評者がこちらを選ぶまでループを続けてください。ビルダーと批評者を並列のサブエージェントとして実行してください。」それ以外の構成はそのまま引き継げます。

記入済みの例を2つ

視覚的な目標。 ユーザー：「ランニングブランドのランディングページ。アスレチックで、緑と暗い色調。活気を感じられるものにしてください。」

提示する基準：A）Nike の現在のランニングキャンペーンページ B）On Running のホームページ C）Gymshark の商品ランディングページ。ユーザーは A を選びます。

Build a landing page for a running brand. Athletic, peak performance, green and dark, energetic, aimed at a young healthy audience. It needs to be interactive and visually unmistakable.

The bar is Nike's current running campaign page. Screenshot it at desktop and mobile and compare against those directly, not against a description of them.

Break this into the smallest pieces that can be improved and judged on their own - hero, motion, type, colour, imagery, interaction, mobile. For each piece, fan out a builder and a separate critic with fresh context. The critic opens the real page in a browser, puts our screenshot next to Nike's blind with the labels stripped, says which is better, and names the single biggest remaining gap. Then it goes back to the builder.

The critic should be a harsh critic. Praise is not useful. If ours does not win, it keeps going.

/loop on each piece until the critic picks ours blind. Do not stop before that.

Keep a live progress page updating as the work evolves so I can watch it.

Fan out subagents and ultracode.

非視覚的な目標。 ユーザー：「エンジニアではない人向けに、ベクトルデータベースについて説明する 2000 語の記事。」

提示する基準：A）Stripe の特定のエンジニアリングブログ記事 B）Julia Evans の特定の記事 C）Wikipedia の記事と理解度テスト。ユーザーは B を選びます。

Write a 2000-word explainer on vector databases for readers who are smart but not engineers.

The bar is Julia Evans' writing on hard technical topics. Pull three of her actual posts and compare against them directly, not against a description of her style.

Break this into the smallest pieces that can be judged on their own - the opening, each explanation, the diagrams, the analogies, the ending. For each piece, fan out a writer and a separate critic with fresh context. The critic reads ours and hers blind with the bylines stripped, says which one a non-engineer would understand faster, and names the single biggest remaining gap. Then it goes back to the writer.

The critic should be a harsh critic. Praise is not useful. If ours does not win, it keeps going.

/loop on each piece until the critic picks ours blind. Do not stop before that.

Keep a live progress page updating as the work evolves so I can watch it.

Fan out subagents and ultracode.

ガントレットのループを破綻させる要因

• 曖昧な基準。 評価者が比較対象を勝手に作り、何でも承認してしまいます。圧倒的に多い失敗です。
• ビルダーが自分の成果物を評価すること。 評価者は、新しいコンテキストを持つ別のエージェントでなければなりません。ビルダーがどれだけ努力したかを知るべきではありません。
• 甘い評価者。 プロンプトで「厳しく」と伝え、二者択一の役割を与えます。つまり、A と B のどちらが優れているかを判断させます。10 点満点の評価は、ラウンドを重ねるごとに上がっていきます。
• N ラウンド後という終了条件。 終了条件は比較に勝つこと、またはユーザーが実行を止めることです。ラウンド数ではありません。
• 指示を細かくしすぎること。 指示が1つ増えるごとに、エージェントが自分の判断で決められることが1つ減ります。シンプルなほうがうまくいきます。