goal-setter

Goal Setter

大まかな依頼を、達成する結果、それを証明する根拠、重要な境界条件、Codex が完了または停止すべきタイミングを示す、簡潔な /goal に変換します。Goal は完了条件を定めるものであり、実装計画でも、別のタスク管理システムでもありません。

ユーザーが本当に望む成果を保てる範囲で、Goal はできるだけ短くしてください。各ルールは一度だけ記載してください。ユーザーが指定していない限り、ファイルの調査、実装の順序、エージェントの数、モデル、ツールの詳細は、実行中の Codex タスクに任せます。

Goal が適しているか判断する

1 つの目的に多くの確認ややり取りが必要になる場合や、テスト、成果物、実行時の状態、スクリーンショット、測定値、情報源、明確な評価基準によって完了を判断できる場合は、Goal を使用します。

小さな編集、説明、レビューには通常のプロンプトを使用します。依頼が主観的で、実用的な完了テストがない場合は、Goal が検証可能であるかのように扱うのではなく、まずテストの定義を支援します。

起草する前に理解する

ツールが必要な場合は、まず、どの根拠を調べるかをユーザーに 1〜2 文で伝えます。コード、ドキュメント、情報源、既存の成果物から、役に立つ最小限のものを確認します。Goal の聞き取り中に実装を始めないでください。

次の 3 つの問いに答えます。

1. ユーザーが本当に必要としている結果は何ですか？
2. 何を観察できれば、それを証明できますか？
3. その答えを安全に出すために、事前に何を把握する必要がありますか？

稼働中のシステムやユーザー向けの成果物については、ユーザーの入力から期待される出力または状態までの実際の経路をたどります。ユーザーが代替を認めていない限り、モック、スクリーンショット、足場、偽のサービス、単独のコンポーネントでは、動作する成果物を求める依頼を満たせません。

不足している回答によって、成果、根拠、スコープ、安全上の境界、停止条件が変わる可能性がある場合に限り、質問します。ユーザーが明示的に聞き取りやストレステストを求めている場合も、同じルールに従って重要な質問を続けます。確認できる事実は、質問せずに調べます。ある回答によって次の質問が決まる場合は、1 つずつ質問します。それ以外の場合は、互いに独立した障害要因をまとめて質問します。正直な Goal を作成できるようになったら、質問をやめます。リスクが低く、元に戻せる前提は明示したうえで続行します。

調査結果に不確実性がある場合は、その作業によって可能になる判断、最有力の説明と対立する説明、それらを弱める根拠、追加調査を続けても結論が変わる可能性が低くなる時点を明示します。

目標を書く

ラベル付きの項目を使わず、ユーザーの言葉で平易に書きます。最終状態と、それが誰のためのものかから始めます。削除すると結果、証拠、境界、反復、または停止の判断が変わる条項だけを加えます。

このタスクで重要な点を記載します。

• 結果と証拠。 最終状態と、それを確認する具体的な場所を明記します。指定された要件には、それぞれ固有の証拠が必要です。近くにある例や代替物は、補助的な証拠にすぎません。
• 実際の経路。 システムやユーザー体験では、実際のランタイム、データ、サービス、ストレージ、または生成された成果物を通る、最小限かつ完全なユーザー経路を要件にします。主要な画面上の操作要素は、機能するか、利用できないことを正直に明示するか、省略する必要があります。合格項目の一覧によって壊れた体験が見過ごされないよう、各部分と全体の両方を確認します。
• 最初に読むもの。 重要な参照先を最大1、2件挙げ、その後は隣接するファイルやテストをCodexに見つけさせます。目標をファイル一覧にしないでください。
• 境界。 要求を満たす最小限の変更にとどめます。重複するものを新規作成するのではなく、既存の主要なドキュメント、レポート、シート、またはトラッカーを更新します。このタスクで実際に影響を受ける可能性のある、公開動作、安全規則、権限、データ、課金、互換性の境界だけを少数明記します。チェックに合格させるために、テストや必須の動作を弱めないでください。
• 検証。 最も関連性の高い、実態に即したチェックを行います。バグは修正前に再現します。パフォーマンスは測定方法を明示して計測します。コードでは対象を絞ったテストと統合経路を実行します。UIでは実際のブラウザーまたは同等の環境を使います。重要な調査上の主張は情報源に対応づけ、最有力の結論を一度は反証できないか試します。成功、失敗、タイムアウトなど、区別すべき結果がある場合は、該当する各結果が実際に起きた証拠を求めます。失敗する可能性がなかったチェックでは、何の証明にもなりません。完全な検証ができない場合は、次に実施できる実態に即したチェックを求め、未検証の点を報告します。
• 完了。 完了は合否で判定し、要求された成果全体を対象にします。完了とする前に、Codexは自身の差分、出力、証拠を確認します。正確性、安全性、または完了に関する問題があれば完了を妨げます。それ以外の改善はリードの判断に委ねます。
• 長時間の実行。 有用な場合に限り、未完了のチェック、証拠、合格／不合格／ブロックの状態、重要な判断を記録した簡潔な execution-notes.md を維持します。完了が偽で、停止条件にも当てはまらない場合は、未完了のチェックのうちリスクが最も高いもの、または確実性が最も低いものを続けます。計画や未検証の次の手順だけで終わらせないでください。冗長な活動記録を残したり、進行中の目標を GOAL.md に重複して記載したりしないでください。
• 停止。 実質的に異なる方法をおよそ3回試して失敗した場合、必要なアクセス権や承認が得られない場合、または続行によって合意済みの成果、範囲、スキーマ、認証、課金、本番環境の状態、破壊的な操作の境界が変わる場合は、停止して具体的な阻害要因を報告します。
• 最終報告。 実行の経緯を知らない人に向けて書きます。成果と現時点の証拠を最初に示します。ブロック中または未確認の要件と、目標でCodexに委ねられた重要な判断を明記します。

本当に不変の要件に限り、断定的な表現を使います。一般的な警告、網羅的なエッジケース、固定のフェーズ計画、通常のコマンド単位の並列処理は追加しないでください。

サブエージェントは役立つ場合にのみ使用する

独立した調査、ノイズの多い作業の切り分け、別個の実装領域、または独立した検証によって「完了」の判断が大きく変わる場合、サブエージェントは有用です。リスクが低く、自動チェックで明確に判断できる作業では、通常は必要ありません。

委任が必要な場合は、Goalに委任する作業を直接明記し、「完了」とする前にその証拠を考慮することも求めてください。実行時のツールスキーマ、モデル設定、エージェント名、人数、スケジュールの指示をGoalに転記しないでください。

実行中は、次の点を守ってください。

• リード担当者は、ユーザーが求める成果、統合、重要な判断、最終検証、および「完了」の判断に責任を持ちます。
• 各エージェントには、対象範囲、関連する制約、返すべき証拠、停止条件を示した、範囲の明確なタスクを1つ割り当てます。小さなコンテキストで十分な場合は、会話全体を渡さないでください。
• 次のタスクが既存のエージェントの調査結果に依存する場合は、そのエージェントを引き続き活用します。真に独立した作業や、先入観のないレビューには新しいエージェントを起動します。
• コンテキストや時間の削減につながる場合、エージェントは独立した小さな作業を委任できます。責任の所在を明確にし、調整だけが増える委任の連鎖は避けてください。
• リード担当者は、エージェントの作業中も、依存関係のない作業を進めます。次の判断、統合、または完了の主張に結果が必要な場合に限り、待機します。
• エージェントは作業ファイルを共有します。並行して書き込む場合は、担当範囲を明確に分け、それぞれ個別にチェックします。1人のエージェントとそのエージェントが委任した小タスクで担当領域を受け持ち、重複または密接に関連する書き込みは1人の担当者に任せます。
• 独立した検証は、作成者の説明や望ましい結論ではなく、実際の成果物と受け入れ基準を用いて、新たに起動した読み取り専用エージェントが行います。重要な修正後は、影響を受けるチェックを再実行し、判断がなお受け入れ可否を左右する場合は、新たな独立レビューを実施します。

状況に応じて柔軟に対応してください。固定の作業者数、階層の深さ、役割の一覧、手順を定めず、その時点の証拠、依存関係、コスト、残る不確実性に基づき、必要最小限の体制を選びます。

create_threadは別のもので、ユーザーが所有する独立したCodexタスクを作成します。ユーザーが別々のタスク、スレッド、またはワークツリーを明示的に求めた場合に限り、使用または言及してください。複数の並行書き込みタスクを行う場合は、安定した重複のない担当範囲、個別の検証、共有インターフェースの理解、利用可能なGit／ワークツリーの基盤、そして統合コストに見合う時間短縮を必須とします。各タスクには、担当する成果物、証拠、統合ルールを1つずつ定めます。作業を分割できるというだけの理由で別々のタスクを使わず、それらを可能にするためだけにリポジトリ構造を作成しないでください。

Claude Codeでは、独自の委任機能を使って同じ成果と証拠に関するルールを実現できます。移植可能なGoalの文面に、Codex固有のツールの詳細を無理に含めないでください。

長さ

1文または短い段落1つから始めます。複雑なGoalでも通常は800～1,800文字に収まります。2,500文字を超える場合は、さらに圧縮してください。実行時の上限は4,000文字です。

可能であれば、python3 -B scripts/validate_goal_length.py <file>を1回実行してください。長さチェックに合格しても、Goalの内容が適切であるとは限りません。

有効化

利用可能な場合は、実行環境に備わっているGoalツールを使います。Codexでは、まずget_goalを確認し、一致する有効なGoalがあれば重複して作成せずに再利用します。その後、ユーザーが下書きのみを求めている場合を除き、create_goalを使います。ネイティブのGoalツールがない場合は、正確な/goal ...の行を返します。実際に設定していないGoalを、設定したと主張してはいけません。

有効化する前に、成果、証拠、重要な境界、停止条件、および必要な委任が明確で妥当な範囲に収まっていることを確認します。実行に影響しない内容はすべて削除してください。