goal-prompt

Goal プロンプト

/goal は、完了条件が満たされるまでエージェントの作業を続けます。Claude Code と Codex は、これを1行（最大4,000文字）として扱います。Claude Code では、小型モデルが各ターンの後に、トランスクリプトだけを基に条件を再評価します。コマンドを実行することはできません。

終了可能な条件を作成してから、形式を整えます。Goal は、確認可能な完了ラインがある、1ターンを超える作業に適しています。小さな Goal をいくつも連鎖させ、間にレビューを挟むようにし、巨大な Goal を1つだけ書くのは避けてください。

作成

AND でつなげて含めます。「または」は使わないでください。ループでは、より低コストの分岐が選ばれます。

1. 作業ではなく終了状態 — 「認証コードを移行する」ではなく、「すべての legacyAuth() 呼び出し箇所で auth.verify() を使う」とします。作業をしたと主張することはできますが、終了状態には真偽があります。
2. 最初に読む対象範囲 — 作業に着手する前に読むファイル、issue、ログ、または計画。
3. 明記されたチェック — 正確なコマンドと観測可能な結果（「npm test が終了コード0で終了する」）に加え、そのコマンドを実行して出力を示すよう指示します。トランスクリプトに結果が残らなければ、評価者にとっては存在しないのと同じです。
4. 不変条件 — 変更してはいけないこと（「vendor/を変更しない」など）。必ず「チェック自体を弱めたり、スキップしたり、編集したりしない」を含めます。
5. 停止上限またはブロック時の指示 — 「または20ターン後に停止する」、「ブロックされた場合は停止して、ブロッカーを報告する」など。これがないと、誤って記述された条件によって無限にループします。フォーマッターは、これがない場合に警告します。（Claude Code はセッション再開時にターンカウンターをリセットするため、ターン上限は再開のたびに実質的に延長されます。）

小さく保ちます。 制約を加えるたびに、モデルが探索できる状態空間は狭まります。可能であれば終了条件を1つにまとめ、対象範囲や定義は参照ファイルに移し、非目標は省きます。制約を含めるのは、実際に抜け道を1つ塞ぐ場合だけにしてください。

長い Goal では、最終的な証拠（diff、レポート、成果物）も明記し、進捗ログファイルを必須にしてください。これにより、コンテキスト圧縮やセッション再開後も状態を保持できます。依頼の内容が4,000文字を超える場合は、詳細を GOAL.md に記載し、目標からそのファイルを参照してください。

不足している要素を決して作り上げないでください。 すべての要素は、ユーザーの依頼、会話、またはリポジトリに基づくものにしてください。推測するのではなく、調べてください。利用可能な情報から要素を補えない場合でも、ユーザーが提示した内容を最適化して形式を整え、その要素は省き、不足として明記してください（「形式を整える」を参照）。成功条件を作り上げると、誤った契約を満たした時点で終了してしまいます。

抜け道を塞ぐ

形式を整える前に、怠けたモデルになったつもりで作成した条件を読み直してください。意図した作業をせずにすべてのチェックを通す、最も低コストな方法は何でしょうか。最も低コストの抜け道を塞ぎます。制約を追加するより、すでにあるチェックを組み合わせることを優先し、考えられるすべての抜け道を非目標として列挙しないでください。よくある抜け道は次のとおりです。

• 修正せず、削除またはスタブ化する — 「検索結果が何も出ない」は、呼び出し元が削除された場合にも当てはまります。このようなチェックは、機能が引き続き動作することを証明するチェックと組み合わせてください。
• 一部だけで合格する — テストファイルを1つだけ実行する、検索パスを狭める、チェック対象からディレクトリを除外する。
• ゲートを不正に通過する — テストをスキップする／xfail にする、期待される出力をハードコードする、テスト入力だけ特別扱いする、チェックを編集する（不変条件のルール）。
• 実行せずに完了を主張する — トランスクリプトにチェック出力がないまま、完了またはブロックを宣言する（出力を示すルール）。

前述と同じ方針です。利用可能な情報から塞げない抜け道は、警告として Missing: リストに含めます。制約を作り上げたり、不合理な制約を課したりするほうが、ギャップを明示するより悪い結果になります。

セキュリティ調査の目標

監査目標を、参照先の脅威モデルファイルに照らして有効な高重大度の脆弱性を1件特定し、発動させ、検証するなど、終了条件を1つに絞ってください。スコープ、攻撃者の能力、重大度の基準、調査対象から除外する既知の発見事項は、目標ではなくそのファイルに記載します。中立的な表現（「悪用可能であることを証明する」ではなく「発動させて検証する」）を使い、前提条件が実証されることを必須としてください。想定した攻撃者のアクセス権は、誤検知の最も一般的な原因です。また、未トリアージの報告を積み上げず、発見ごとに人間によるレビューを行ってください。発見事項は、発見者だけでなく、別の新しいエージェントによる2回目の確認で検証してください。

形式

ドラフト（ファイルまたは標準入力）に対して uv run --no-project {baseDir}/scripts/format_goal_prompt.py --fenced を実行してください。空白を1行にまとめ、/goal のプレフィックス、引用符、コードフェンスを削除し、停止条件がない場合は警告を出します。また、4,000文字を超える出力は拒否されます。その場合は短くするか、詳細をファイルに移してから再実行してください。

text のコードフェンス1つだけを、1行で返してください。

/goal <single normalized objective>

その前後に説明文を追加しないでください。ただし、チェックリストの要素を根拠に基づいて記述できない場合は、コードブロックの後に Missing: リストを続け、各不足項目を1行ずつ記載して、ユーザーに提示が必要な情報を伝えてください。

例

ドラフト：

/goal Migrate the auth module:
  - replace legacyAuth() with auth.verify()
  - make sure the tests still work

書き直して整形したもの：

/goal All legacyAuth() call sites use auth.verify(): `rg "legacyAuth\(" -t ts` prints nothing AND `npm test` exits 0 (run both, show the output), without modifying vendor/ or weakening any test. If blocked, stop and report attempted paths and the blocker, or stop after 20 turns.

ここでは npm test は推測ではなく、リポジトリの package.json に基づいています。また、これに一致がないことの確認を組み合わせることで、最も手軽な抜け道、つまり移行せずに呼び出し箇所を削除する方法を防げます。要素の根拠となる情報が何もない場合は、存在する内容を整形し、不足項目を明示してください。

ドラフト：コンテキスト内にメトリクスやベンチマークがまったくない場合の make checkout faster：

/goal Make checkout faster

Missing:

• 測定可能な終了状態 — 「高速化」の基準となるメトリクスとしきい値
• 検証方法 — その結果を証明するベンチマークまたはコマンド
• 停止条件 — 例：「または20ターンで停止する」