Goal Prompt
/goal は、完了条件が満たされるまでエージェントを動作させ続けます。Claude Code と Codex はどちらも 1 行、最大 4,000 文字として受け取ります。Claude Code では、各ターン後にトランスクリプトのみから小さなモデルが条件を再評価します — コマンドを実行することはできません。
終了可能な条件をドラフトし、それを整形します。goal は 1 ターンより大きな作業に適合し、確認可能なゴールラインを設定します。巨大な goal を 1 つ書くのではなく、小さな goal を連鎖させ、それらの間にレビューを挟みます。
ドラフト
AND で結合します — 「or」は決して使わないでください。ループは安い方の分岐を取ります：
- アクティビティではなく、終了状態 — 「auth コードを移行する」ではなく、「すべての
legacyAuth()呼び出し箇所がauth.verify()を使っている」。アクティビティは主張できますが、終了状態は真または偽です。 - 最初に読むスコープ — 行動する前に読むファイル、issue、ログ、または計画。
- 明示されたチェック — 正確なコマンドとその観測可能な結果（「
npm testが 0 で終了する」）、さらにそれを実行して出力を表示する指示。トランスクリプトに決して現れない結果は、評価者にとって存在しません。 - 不変条件 — 変更してはならないもの（「vendor/ を変更せずに」）、常に「チェック自体を弱めたり、スキップしたり、編集したりしない」を含めます。
- 停止条件またはブロック句 — 「または 20 ターン後に停止」、「ブロックされた場合は停止してブロッカーを報告」。これがないと、誤った条件が無限ループを引き起こします。フォーマッタはこれが欠けている場合に警告します。（Claude Code はセッション再開時にターンカウンタをリセットするため、ターンバウンドは再開をまたいで暗黙的に延長されます。）
小さく保ってください。 すべての制約は、モデルが探索できる状態空間を狭めます。可能な場合は 1 つの終了条件にまとめ、スコープと定義は参照ファイルに移動し、非目標を削除します — 制約は、実際の簡単な抜け道を塞ぐ場合にのみその価値を発揮します。
長い goal の場合は、最終的な証拠（diff、レポート、アーティファクト）に名前を付け、進捗ログファイルを要求します — これは圧縮と再開にわたって持続する状態です。概要が 4,000 文字を超える場合は、詳細を GOAL.md に入れ、そのファイルを objective から参照します。
不足している要素を決して発明しないでください。 すべての要素をユーザーのリクエスト、会話、またはリポジトリに基づかせてください — 推測ではなく調査してください。利用可能な情報から要素を埋められない場合は、それでもユーザーが提供したものを最適化して整形し、その要素を省略し、不足としてフラグを立てます（フォーマットを参照）。発明された成功条件を持つ goal は、間違った契約で終了します。
簡単な抜け道を塞ぐ
整形する前に、ドラフトした条件を怠惰なモデルのように読み直してください：意図された作業を行わずにすべてのチェックを通過させる最も安い方法は何ですか？最も安い方法を塞ぎます — 制約を追加するよりも、既存のチェックをペアリングすることを優先し、考えられるすべての抜け道を非目標リストに列挙しないでください。繰り返し発生する抜け道：
- 修正ではなく削除またはスタブ化 — 「検索で何も表示されない」は、呼び出し元が存在しない場合にも成立します。そのようなチェックは、機能がまだ動作していることを証明するチェックとペアにします。
- サブセットで合格 — 1 つのテストファイルだけを実行する、検索パスを狭める、チェックからディレクトリを除外する。
- ゲートをごまかす — テストをスキップ/xfail する、期待される出力をハードコードする、テスト入力を特殊ケース化する、チェックを編集する（不変条件ルール）。
- 実行せずに主張 — トランスクリプトにチェック出力がないまま、完了またはブロックされたと宣言する（出力表示ルール）。
上記と同じ規律：利用可能な情報から塞げない抜け道は、警告として Missing: リストに入れます — 発明されたり馬鹿げた制約は、フラグが立てられたギャップよりも悪いです。
セキュリティ研究の goal
監査の goal は 1 つの終了条件にまとめます。例えば、参照される脅威モデルファイルの下で有効な 1 つの高深刻度の脆弱性を特定、トリガー、検証することです。そのファイル（goal ではありません）に、スコープ、攻撃者の能力、深刻度のベースライン、およびスキップする既知の調査結果を記述します。中立的な表現を使用し（「これが悪用可能であることを証明する」ではなく「トリガーして検証する」）、事前条件の実証を要求します — 想定された攻撃者アクセスは最も一般的な false positive です — そして未トリアージのレポートが積み重なるのを防ぐため、発見ごとに人間のレビューのために停止します。発見は、発見者単独ではなく、新しいエージェントによる 2 回目のパスで検証します。
フォーマット
ドラフト（ファイルまたは標準入力）に対して uv run --no-project {baseDir}/scripts/format_goal_prompt.py --fenced を実行します。これにより、空白が 1 行にまとめられ、/goal プレフィックス、引用符、フェンスが削除され、stop 句がない場合に警告し、4,000 文字を超える出力を拒否します — 短くするか、詳細をファイルに移動して再実行します。
正確に 1 つのフェンスで囲まれた text ブロックを 1 行で返します：
/goal <単一の正規化された objective>
その周りに散文を追加しないでください — ただし、チェックリストの要素が根拠付けられなかった場合を除きます：その場合は、ブロックの後に Missing: リストを、ギャップごとに 1 行、ユーザーが提供すべきものを伝えて続けます。
例
ドラフト：
/goal auth モジュールを移行する：
- legacyAuth() を auth.verify() に置き換える
- テストがまだ動作することを確認する
再ドラフトして整形：
/goal すべての legacyAuth() 呼び出し箇所が auth.verify() を使用：`rg "legacyAuth\(" -t ts` で何も表示されず AND `npm test` が 0 で終了する（両方を実行し、出力を表示）、vendor/ を変更したりテストを弱めたりしない。ブロックされた場合は、試行したパスとブロッカーを報告して停止する。または 20 ターン後に停止する。
ここで npm test はリポジトリの package.json から来たものであり — 推測ではありません — そしてそれをゼロマッチのチェックとペアにすることで、最も安い抜け道である「呼び出し箇所を移行するのではなく削除する」を塞いでいます。要素を根拠付けられるものがない場合、存在するものを整形し、ギャップにフラグを立てます：
ドラフト：チェックアウトを速くする、コンテキスト内にメトリックやベンチマークがない場合：
/goal チェックアウトを速くする
Missing:
- 測定可能な終了状態 — どのメトリックとしきい値が「速い」と見なされるか
- 検証 — それを証明するベンチマークまたはコマンド
- 停止条件 — 例：「または 20 ターン後に停止」