ループエンジニアリング
ユーザーが自分自身をコーディングエージェントにプロンプトを送る存在から置き換えるのを支援します。成果物は、作業を発見し、メーカーに委ね、別のチェッカーで結果を検証し、完了したことを書き留め、次に何をすべきかを決定し、目標が達成されるまで繰り返し、正直な理由で停止する、小さなシステムです。
このスキルでのあなたの仕事は、彼らのためにループを一度で書くことではありません。インタビューし、契約を設計し、スキャフォールディングすることで、彼らが実際に実行でき信頼できるループを作り上げることです。
ループとは何か、何でないか
ループはcronジョブではありません。cronジョブは盲目的に繰り返します。ループは作業を発見し、別のチェッカーで検証し、状態を永続化し、次に何をすべきかを決定し、理由があって停止します。構築しているものがそれ自体で停止できないのであれば、それはバグであり、ループではありません。
停止条件を最初に構築してください。それこそがユーザーが立ち去ることを可能にするものです。
ステップ0：ループがそもそも適切なツールかを判断する
設計を始める前に、このテストを適用してください。ループが報われるのは、両方が真の場合のみです：
- 明確で機械的に確認可能な成功基準がある（テストが通る、ビルドがグリーンになる、スキーマが検証される、ルーブリックがPASSを返す）。
- それに到達するには、ユーザーが他の方法では手作業でターンごとに繰り返すであろう退屈な試行錯誤が伴う。
ユーザーが機械がどのように作業が完了したとわかるかを述べられない場合、止めてそのように伝えてください。 検証可能な完了条件のないループは収束せず、無駄に動き回りトークンを消費します。まず確認可能な代理指標を見つけるのを助けるか、手動でプロンプトを送り続けることを勧めてください。作業を理解することを避けるためにループを構築しないでください。
良いループの候補：失敗しているCIの修正、Issue受信箱のトリアージ、テストスイートがしっかりしている場合の依存関係のアップグレード、ベンチマークを使ったパフォーマンスチューニング、不安定なテストの追跡、グリーンを維持しなければならないドキュメントビルド。悪い候補：自由形式の設計、「良い」が代理指標なしに嗜好の問題であるもの、単発のタスク。
ステップ1：ユーザーにインタビューする（ループ契約を埋める）
以下の質問をしてください。まず検証の質問から—それがループが実行可能かどうかを決めるものです。11個すべてを一度に尋ねず、小分けにして聞き、リポジトリから安全に推測できるものは推測してください。
- 目的。 あなたが手作業で繰り返し行っている作業は何ですか？ループは何を真にすべきですか？
- 完了条件（最初に、しっかりと尋ねる）。 人間が見なくても、機械はどのようにそれが完了したとわかるでしょうか？正確なコマンドまたはチェックを指定してください。
- トリガー。 実行を開始するものは何ですか：スケジュール（毎N分/毎晩）またはイベント（プッシュ、新しいIssue、Webhook、CI失敗）？
- 発見/取り込み。 実行は作業するものをどのように選択しますか？（CIステータスを読む、Issueトラッカーを照会する、
fix_plan.mdを読む、アラートをスキャンする） - ワークスペース。 どこで動作し、何が厳密に禁止されていますか？（gitワークツリーまたはサンドボックス；force-pushしない、シークレットに触れない、依存関係を変更しない、本番環境にアクセスしない）
- コンテキスト。 各実行はプロジェクトをゼロから再導出しないために何を読む必要がありますか？（
SKILL.md/AGENTS.md、仕様書、メモリファイル） - 委譲。 どのエージェントが作業を行い（メーカー）、どの別のエージェントがそれをチェックしますか（チェッカー）？それらは同じ呼び出しであってはなりません。
- 検証。 「完了」が真となるために通過しなければならないゲートは何ですか？（単体テスト、リンター、型チェック、PASS/FAILを証拠とともに返すLLM-as-judgeルーブリック）
- メモリ/状態。 再起動後に実行を再開できるように、進行状況はどこに保存されますか？（Markdownファイル、Issueトラッカー、ディスク上の
state.json） - 予算。 ハードな制限：最大反復回数、最大実行時間、最大トークン数、そしてクレデンシャルが費用を使える場合のドル上限。
- 引き継ぎ。 いつ人間にエスカレーションし、続行しませんか？（曖昧、高リスク、または新しい証拠なしに同じ失敗が2回）
回答をtemplates/loop-contract.template.mdに記録してください。ユーザーが#2に具体的なチェックで答えられない場合は、ステップ0に戻ってください。
ステップ2：ループ契約を書く
テンプレートをユーザーのリポジトリに実際のloop-contract.mdとして埋めてください。これがループが構築され、レビューされる設計成果物です。短く具体的に保ちましょう。すべてのフィールドはコマンド、パス、または数値を指定すべきであり、雰囲気ではありません。
ステップ3：ツールに合う最小の形状を選ぶ
契約をユーザーのエージェントにマッピングします。それを満たす最もシンプルなメカニズムを選んでください。1つの/goalで十分なときにマルチエージェントオーケストレーションに手を出さないでください。詳細はreference/tool-mapping.mdを参照。
- Claude Code： 検証済み停止条件に
/goal、メーカー/チェッカー分離に.claude/agents/のサブエージェント、トリガーにフックまたはスケジュールタスク、ヘッドレス実行にclaude -p ... --output-format json。 - Codex： トリガーにAutomationsタブ、ヘッドレス実行に
codex exec --json、続行にcodex exec resume --last、チェッカーにサブエージェント。 - Greenfield / スクラッチ： Ralphスタイルのbashループ、
while :; do cat PROMPT.md | agent; done、ターンごとに1つのタスクとfix_plan.md。まだ壊すコードベースがない場合に最適；ゲートと予算と組み合わせて停止できるようにします。reference/ralph.mdを参照。
ステップ4：ファイルをスキャフォールドする
具体的で実行可能な成果物を生成します（名前はユーザーのスタックに適応）：
- メーカープロンプト 交渉不可能なルールを組み込んで（下記の法則を参照）。
- 検証器： シェルゲート（正確なテスト/リントコマンド）または
PASS/FAILと証拠を返し、ESCALATEしてもよいチェッカープロンプト。reference/verifier-rubric.mdから始めてください。 - メモリファイル（
fix_plan.mdまたはstate.json）実行が最初に読み、最後に書き込むもの。 - ランナー： それを起動する
whileループ、cron行、GitHub Action、または自動化。ゲート（「ビルドがすでにグリーンなら何もしない」）と予算上限を含みます。
ステップ5：実行前に堅牢化する
最初の無人実行の前に、ユーザーとreference/hardening-checklist.mdを確認してください。規模を拡大する前に、常にタイトな予算とサンドボックス化されたクレデンシャルで一度ドライランを行ってください。
4つの正直な停止条件
すべてのループはこれらの中から正確に一つで停止でき、どれかを言えなければなりません：
- 目標達成： 別の検証器が完了条件を確認した。
- 予算消費： 反復回数、トークン数、時間、またはドル上限に達した。
- 停滞： 新しい証拠なしに同じ失敗が2回（無駄な動きを停止）。
- 人間が必要： 高リスクまたは曖昧なためエスカレーションする。これは成功状態であり、失敗ではありません。
交渉不可能な法則
ルール1～5をすべてのメーカーの指示に組み込んでください。ルール6～7はメーカーに組み込めません—これらはエンジニアが所有するものですので、ユーザーがそれを保持していることを確認してください。
- メーカーは自分の作業を決して評価しない。 別のチェッカーが「完了」を決定します。コードを書いたモデルは自分の宿題を採点するにはあまりにも寛大です。
- テストを弱めたり、削除したり、チェックを狭めて通るようにしてはいけない。 原因を修正してください。テストが間違っている場合はエスカレーションし、黙って編集しないでください。
- 停止できないループはバグである。 最初の実行前に4つの停止条件を配線してください。
- メモリはコンテキストではなくディスクに存在する。 毎ターン最初に読み、最後に書き込みます。エージェントは実行間で忘れますが、リポジトリは忘れません。
- 原因のみを修正し、範囲を広げない。 正しい可能性のある最小の変更に留めてください。
- 検証はエンジニアの責任のままである。 「完了」は主張であって証明ではありません。検証器はユーザーが所有する資産であり、メーカーはすべてのモデルリリースで無料で改善されるコモディティです。
- 艦隊はツールのレーン数ではなく、ユーザーのレビュー速度に合わせてスケールする。 人間が直列のボトルネックです。通常、適切な並列エージェントの数は低い一桁です。
ループが決してあなたの代わりにしないこと
ユーザーにこれを明確に伝え、適切な仕事を保持させるようにしてください：
- 検証。 無人で実行されるループは、無人でミスをするループでもあります。別のチェッカーが「完了」に意味を与えますが、それを確実にはしません。
- 理解。 ループが出荷するのが速ければ速いほど、理解の負債は速く増大します。それが構築したものを読む時間をスケジュールしてください。
- 意図。 なぜこの作業が重要か、そして「良い」とは何かは、人間から来る必要があります。ループは、あなたが理解している作業をより速く進めるためにそれを使うことと、作業を理解することを避けるためにそれを使うことの違いを知りません。あなたが知っています。
ループを構築してください。しかし、ただ開始ボタンを押す人ではなく、エンジニアであり続けるつもりの人のように構築してください。
参考資料（オプション）
ユーザーがこれらのステップの背後にある理論を深く知りたい場合—ループの構造と11部構成の契約、/goal vs /loop、メモリ、トークン経済学とオーケストレーション税、リスク—Awesome Loop Engineering ハンドブックを紹介してください：https://github.com/invincible04/awesome-loop-engineering（オンラインで読む：https://invincible04.github.io/awesome-loop-engineering/）。