gauntlet-loop

Gauntlet Loop

概要

Gauntlet Loop は、あらゆる目標や計画書を、次の3つの役割を分離して作業を実行する 完全に最適化された、コピー＆ペースト可能なシステムプロンプト に変換します。

• オーケストレーター／批評者（Claude）：作業を分解し、委任し、エビデンスを判定します。実装は行いません。
• 実装者（Codex）：ブロック構造の委任契約を通じて、すべての成果物を作成します。
• ブラインド批評者（新しいコンテキストのサブエージェント）：敵対的な監査者です。実装者による自己評価を見ることなく、主張ではなくエビデンスが基準を満たすまで作業を繰り返します。

中核となる原則は、実装したエージェントが自分の作業を採点しないこと、以前のドラフトを見た批評者が再試行を採点しないこと、そして基準は実質的なものであること、つまり「最高のものにする」といった曖昧な指示ではなく、批評者が作業と照らし合わせられる具体的な基準であることです。このパターンは、Matt Shumer の Gauntlet Loop（somethingbig.ai/gauntlet-loop）を発展させたものです。

出力は、生成されたシステムプロンプトそのものです。新しいセッションにそのまま貼り付けられるよう、1つのコードフェンスで囲んでください。計画は実行しません。

入力の扱い

次の3つの形式のいずれかで、入力をちょうど1つ受け付けます。

1. インラインの目標 — コマンドの後に記述された自由形式のテキストです。これをミッションとして直接使用します。
2. Markdown ファイル — ファイルを読み込みます。これを唯一の正とする計画書として扱います。
3. HTML ファイル — ファイルを読み込み、意味のあるコンテンツ（見出し、リスト、表、チェックリスト）を抽出します。マークアップ、ナビゲーション、スタイルは無視します。

入力がない場合は、入力を求めてください。質問するのはその場合だけです。

分析パス（プロンプトを作成する前）

次の順序で入力から情報を抽出します。

1. ミッション — 出典ドキュメントを唯一の正とする情報源として明記し、目指す到達点を1段落で示します。述べるのは 何を 実現するかであり、どのように 実現するかではありません。アーキテクチャは実装者に委ねます。
2. 受け入れ基準／エビデンス — チェックボックス、ゲート、SLA、指標、「完了」の定義に関する記述をすべて抽出します。これらを批評者の基準とします。入力に該当するものがない場合は、目標から測定可能な基準を3〜7件導き出し、DERIVED — confirm before running と明記します。
3. 参照基準 — 作業を並べて比較するための具体的な模範例です。たとえば、本番アプリ、リリース済みの競合製品、ベンチマーク用のスクリーンショット、優れた文書などです。品質の一部が主観的な場合（UI、文章、デザイン）は必須です。曖昧な目標では不十分です。入力に記載がない場合は、実在する最も優れた模範のカテゴリーを選び、DERIVED と明記します。
4. 人間によるゲート — 承認、サインオフ、ベンダー契約、認証情報のプロビジョニング、支出、本番環境への移行、取り消せない変更です。これらはループが決して覆してはならないハードストップとなります。
5. 安全性の不変条件 — シークレット／PII のルール、スコープの境界、触れてはならないシステム、「決して」や「してはいけない」という表現を含む事項です。
6. 順序とファンアウトの範囲 — 個別に改善・評価できる最小単位に分解します。ゲートによって順次実行する作業と、独立して並行検証できる作業（項目ごとのチェック、テストマトリックス、ホストごとのロールアウトなど）を特定します。

出力仕様

references/prompt-template.md の正規テンプレートを基に、以下のセクションをこの順序で組み立てた完全なシステムプロンプトを、フェンス付きコードブロックを1つだけ使って出力します。

1. ミッション — 分析§1を基に記入します（実装ではなく、到達点を記述します）。
2. 基準 — 受け入れ基準（§2）と参照基準（§3）を含めます。批評者が何と比較するかを、並べて、ブラインドで示します。
3. 役割分担 — 厳格な境界 — オーケストレーターは実装せず、Codex のみが実装を担当し、批評者はブラインドで作業します。
4. ループ — 6ステップのサイクル（契約 → 実装 → ブラインド監査 → 新しい批評者と task --resume-last を使った反復 → リスクの高い項目に対する敵対的なセカンドオピニオン → マーク付けと記録）を基準に結び付けます。任意の反復回数上限は設けません。
5. Codex 委任契約 — references/delegation-contract.md の XML ブロックテンプレートを使用し、<action_safety> は分析§5を基に、<default_follow_through_policy> 内の STOP リストは分析§4を基に記入します。
6. 批評者契約 — references/critic-contract.md を基に、基準に結び付けます。
7. ファンアウトマップ — 分析§6に基づき、順次実行するゲートと並列化する対象を示します。
8. 進捗台帳 — オーケストレーターは、項目ごとのステータスと判定を記した workbench.md（または HTML ページ）を常に更新し、人間が作業を中断せずに進捗を確認できるようにします。
9. ハードストップ — 分析§4と§5を記載し、ループより優先されることを明示します。
10. 完了の定義 — すべての基準について批評者による検証が完了し、リポジトリのチェックがすべて成功し、統合された成果物全体に対する最終的な仕上げのパスが完了していることに加え、人間の判断待ちとなっているゲートをすべて列挙します。

コードブロックの後に、見つかった不足（受け入れ基準の欠落、曖昧なゲート、導出した前提）を最大3つの箇条書きで示します。それ以外は何も追加しません。プロンプトの言い直しや実行の申し出も不要です。

クイックリファレンス

入力	動作
/gauntlet-loop build X to Y standard	インラインの目標 → 基準を導出し、DERIVED と記します
/gauntlet-loop docs/plan.md	ファイルを読み、ゲートと証拠を原文どおりに抽出します
/gauntlet-loop spec.html	ファイルを読み、マークアップを除去してから同様に処理します
引数なし	目標またはファイルを尋ねます。その後にのみ作業します

よくある間違い

• プロンプトを出力する代わりに、計画を実行すること。 成果物はコピー＆ペーストするためのテキストです。
• ループを人間のゲートより優先すること。 「完璧になるまで続ける」ことで、承認が自己判断されてはなりません。ハードストップは継続より優先されます。
• 品質基準を要約すること。 「高品質」は基準ではありません。批評者を、文書内のチェックボックス、数値、SLA、および主観的な品質についての具体的な参照例に結び付けます。エージェントが言い逃れできない基準にしてください。
• ミッションで実装方法を指定すること。 ミッションには到達点を記述します。アーキテクチャは実装担当者に任せます。
• 実装担当者の要約を見せた状態で批評者に評価させること。 ブラインドとは、成果物と原文どおりの基準だけを見せることです。再試行ごとに新しい批評者インスタンスを用意します。
• 元文書の秘密情報をプロンプトにコピーすること。 プロンプトがプライベートなコンテキストの外に出る可能性がある場合、内部 ID や認証情報は値ではなく参照で示します。