next-goal

次の目標

リポジトリの根拠に基づいて、対応可能な重要な次の目標のスコープを見つけます。現在または以前のリクエストで明確なスコープを選択してください。次の目標の選択を求めるリクエストは、スコープの選定を委ねるものです。最も根拠のある境界を選んでください。実行可能なスコープが1つしかない場合は、ユーザーが先に選択またはプレビューを求めていない限り、それを選択します。ユーザーの指示または委ねられた判断で解決できない、実質的に異なる結果が残る場合にのみ質問してください。

選択したスコープを再検証し、準備状況のゲートを通過させ、想定される変更規模に基づいて PR としての提出、または後の集約を推奨し、簡潔で新鮮なセッション向けのルーティング用エンベロープを、明確な実行契約とともに1つ作成します。スコープの選択に、ユーザーとの別ターンは必要ありません。目標プロンプトを返すときは、前提条件の結果をコメント欄に記載し、最終回答をそのまま /goal にコピーできる形にします。目標を実行するセッションで永続的な目標状態を初期化できるよう、契約に $progress による目標追跡を含めます。推奨しない提出用プロンプトを生成するのは、ユーザーがその形式を単独で、または推奨案と併せて明示的に求めた場合に限ります。

スコープの発見と選択は読み取り専用のままにします。準備は、以下で説明する別途承認されたフェーズです。準備が完了したら、更新後のリポジトリ状態から同じ境界を再検証します。

操作を選択する

以下は明示的なスキルの指示であり、シェルコマンドではありません。

呼び出し	承認された操作
$next-goal	プロンプトを選択して返します。デフォルトでは変更しません。
$next-goal prepare	選択し、詳細な計画を完成させてレビューし、関連する準備をコミットしてから、プロンプトを返します。
$next-goal spawn [model] [reasoning]	準備を行い、準備済みの状態から Codex タスクを1つ新規作成し、そこでネイティブの目標を開始します。

これらのデフォルトよりも、明示的なプロンプトのみ、プレビュー、コミット禁止、または待機の指示を優先します。引用、例、スキル設計の議論での言及は、実行の依頼ではありません。モデル引数を使用するのは spawn の場合のみです。モデル名だけからタスクの作成を推測しないでください。明示された呼び出しポリシーは変更しないでください。

prepare と spawn では、変更を加える前に 目標の準備 を読んでください。準備によって承認されるのは、計画の作成とそのスコープ内でのコミットであり、実装や既存作業全体の包括的なコミットではありません。ユーザーがすでに下した決定と、委ねられた判断を活用してください。それらでは解決できない重要な決定についてのみ質問してください。

spawn では、準備の前に Codex の目標を作成する も読み、機能、対象、引数を確認してください。このモードは、選択したプロジェクトで現在の準備済み Git 状態から開始する新しいタスクを明示的に要求するものです。通常のサブエージェントを意味することはありません。モデルのエイリアスは astra（GPT-6 Astra、medium）と luna（GPT-5.6 Luna、max）です。正確なツール引数と任意の上書きは、spawn ワークフローが管理します。モデルの指定がない場合は、デフォルトで astra medium を使用します。明示されたモデルと推論の上書きは尊重してください。

結果を確定するためにステップ1～3を実行します。prepare または spawn モードの場合は、その後、準備ワークフローを実施し、準備状況のゲートに進む前にステップ1～3を再検証します。既存の複合ワークフローと同様に、独立して依頼された前提条件の編集またはコミットは、最初のスコープ探索より先に完了してもかまいません。計画の修正や追加の回答でも、選択した操作を維持してください。完了済みの準備を繰り返したり、タスクを重複して作成したりしないでください。

1. 現状を把握する

1. 該当する AGENTS.md ファイルを読み、正式に有効な PLAN、TODO、ROADMAP、進捗、または引き継ぎドキュメントを特定します。ユーザーが指定したドキュメントを優先し、指定がない場合はリポジトリの慣例やリンクに従います。複数のワークツリーやスコープ別のロードマップがある場合は、現在のワークツリーの計画用名前空間を選びます。明示的に全体目標を求められた場合に限り、ほかのスコープも確認します。計画がない場合は、指示、コード、テスト、履歴から候補を推定します。
2. Git の状態と最近の履歴を調べたうえで、計画に古い記述がないか、作業が完了していないか、実際の前提条件やブロッカーがないかを確認するために必要な範囲で、実装と検証の証拠を読みます。
3. 候補となる成果、制約、不足している証拠、重要な未解決の判断事項を特定します。ユーザーが判断する実装上の疑問は、準備状況の確認まで保留してください。そうすれば、各質問に委任か修復かの選択肢を必ず含められます。目標の境界を選ぶ作業は、次のスコープ選択ステップで行います。

このステップは、計画をそのまま受け入れるのではなく、リポジトリと照らし合わせて、現在のプロジェクトの状態、候補となる成果、重要な不足事項を検証できた時点で完了です。

2. スコープを決定する

既存のスコープ選択または委任された判断を適用するか、実行可能なスコープが1つだけならそれを選びます。境界が未確定のままの場合、またはユーザーが選択肢を求めている場合は、実質的に異なる、十分な規模の目標境界を簡潔にまとめて提示します。名前付きの作業範囲やチェックリスト項目は計画単位として扱い、自動的に選択肢や終了地点にしないでください。選択肢は成果や一貫した中断地点によって異なっていて構いませんが、隣接する作業のあらゆる組み合わせを列挙しないでください。証拠に裏付けられる場合は2～4件を目安とし、件数を満たすために実現性の低い選択肢を作らないでください。

各選択肢には、判断に必要な境界だけを記載します。

• 目指す意味上の成果。
• 対象に含む成果。目標契約にまで細分化せず、要約して記載します。
• 直後に控える成果またはマイルストーンのうち、どこまで進めて終了するか。
• 準備が整っているか、選択後に委任または修復を要する具体的な計画上の不足があるか。

選択肢を提示する際は、ちょうど1つに (Recommended) を付け、その理由を簡潔な1文で説明します。成果の価値、一貫性、計画の準備状況、ブロッカーのリスク、後続マイルストーンとの切り分けを考慮しながら、目標を継続的に進めるエージェントが自律的に取り組める、最も有用な成果を優先します。スコープの推奨は、後段のデリバリー推奨とは別のものです。

選択の回答が必要な場合、提示する選択肢を正確に表現できるなら構造化された選択コントロールを使用し、できない場合は番号付きリストを使います。ユーザーには、番号または名前で選ぶか、境界の調整案を提示するよう求めます。フェンス付きの目標プロンプトは出力しないでください。今すぐ実装できる、または範囲を限定した委任や計画の修復によって準備を整えられる、十分な候補が残っていない場合は、オプションを作り出さずに /goal は適切ではないと伝え、終了します。計画上の不足がある有力な候補は選択肢に残し、選択後の準備状況確認で対処できるようにします。外部の承認や未解決の外部ブロッカーに依存する作業は提示しないでください。

未解決のスコープ選択を待つ場合、または先に選択肢を提示するよう求められた場合に限り、ここで終了します。それ以外の場合は同じターン内で続行します。デリバリー方法の違いだけでは、実質的に異なる境界が未解決のままのスコープは決まりません。

3. 選択した目標境界を確定する

選択したスコープを現在のリポジトリの状態と照らし合わせて再検証してから、確定します。重要なリポジトリの変更によって境界が無効になった場合は、適用される委任権限に従ってスコープを再調整します。その権限では変更後の判断を解決できない場合は、ユーザーに確認します。そうでない場合は、推奨と異なっていてもユーザーが選んだ境界を維持します。 オプションの範囲を定めるときも、選択した範囲を最終確定するときも、これらの境界ルールを適用してください。自然につながる作業はオプションに含めても構いません。また、選択した範囲を調整した場合は、意味的に完結させるのに必要な分だけ精緻化できます。1つの有意義なプロジェクト状態につながるのであれば、目標は複数のサブシステムや、まとまりのある複数のコミットにまたがっても構いません。

両方のデリバリー形式が求められている場合は、選択した範囲を両者で同一にしてください。PR 形式では、大きな目標の中のデリバリーチェックポイントとして PR を扱い、別個の /goal 境界として扱わないでください。

選択した範囲は、次の条件を満たす必要があります。

• 通常の対話1ターンで対応できる作業よりも、実質的に大きいこと。
• 前提条件や内部の接続点だけでなく、具体的で実証可能なプロジェクトまたはユーザーの成果に到達すること。
• 複数のチェックポイントにまたがる永続的な実行から恩恵を得られるよう、確定済みまたは明示的に委任された作業を十分に含むこと。
• Readiness Gateで解決も委任もされない重大な未解決の意思決定、外部からの承認、ブロッカー、または実質的に無関係な次のマイルストーンで終えること。次の計画見出しやレビュー可能な一部分だけを区切りにしないでください。

選択した範囲が小さい場合は、適用されるユーザーの指示や委任された選択権限を超えて拡大しないでください。選択肢が /goal に適するほど十分な規模でない場合は、その旨を説明して範囲の選択に戻り、黙って置き換えないでください。十分な規模があるものの計画が未完了の選択範囲は、ゲートに進みます。

Readiness Gateの前に、選択した範囲を次の閉じたルーティング用エンベロープに整理してください。

• 成果 — プロジェクトまたはユーザーにとっての結果を、意味が通る1文で示します。
• 目標状態 — 永続的なパスを1つ指定します。通常の作業では goals/<stable-slug>.md、分離されたワークツリーの計画範囲では goals/<scope>/<stable-slug>.md とします。
• 含まれる成果と情報源 — 承認された成果をすべて、短く安定した意味上のラベルで示し、それぞれの実装と受け入れ基準の詳細を記す、権威ある文書を必要最小限だけ組み合わせます。ラベルが範囲への所属を定義します。パスやキュー内の位置は定義しません。
• 完了条件 — 名前が付いた各成果が、引用された結果と該当する完了基準を満たすことに加え、情報源にすでに含まれていない横断的な検証、レビュー、鮮度、およびデリバリー条件のみを要求する、簡潔な述語を1つ定めます。
• 除外作業 — 範囲外となる直近の次のマイルストーンと、ユーザーが直接示した除外事項だけを記載します。それ以降の項目、無関係な項目、または計画に記載されているだけの項目すべてについては、権限の範囲で完全に定めます。
• 権限 — 含まれる成果に必要な、最小限の範囲の作業のみを許可します。委任によってReadiness Gateを通過した場合は、閉じた成果の範囲内で残る意思決定を、目標実行エージェントが最善の判断で解決することも許可します。範囲外の事項は後のために記録し、選択済みの契約とデリバリーライフサイクルで認められていない拡大や外部アクションには、明示的なユーザーの指示を必須とします。
• 再開時の不変条件 — 作業を再開する各ターン、自動継続、コンパクションからの復旧、または引き継ぎの際は、目標モードで $progress を呼び出し、さらに作業を選択または開始する前に、指定された目標状態を復元してください。
• デリバリー — 選択したライフサイクルとそのスキルへの振り分けを、復旧時にも維持できるよう契約の範囲内に収めます。

証拠が揃わず、フィールドを確定できない場合は、正確な計画上の不足を記録してください。確定したように装ってはいけません。境界の最終確定が完了するのは、選択した範囲、その暫定エンベロープ、および未対応のフィールドすべてがReadiness Gateに進める状態になったときです。

目標への作業の所属は閉じたものとして扱ってください。ロードマップを進めること、Current を変更すること、計画を作成すること、ブランチや PR を開くこと、またはレビューでの指摘を発見することによって、目標に作業が追加されることはありません。プロジェクトの計画状態は次に何をすべきかを示しますが、この実行で許可される作業は目標契約だけが定めます。

4. 準備状況のゲートを通過する

目標プロンプトを出力する前に、根拠によって、結果が確定していること、意味的に含まれる成果と信頼できる情報源、完了の判定条件、自律的な実装に十分な方針が固まっていることを確認してください。実装担当者が所有する、取り消し可能な選択は未決定のままでもかまいません。ユーザーが所有する重大な決定には、明示的な委任または計画の修正が必要です。

結果は確定しているものの、重大な決定が残っている場合は、まずユーザーがすでにその決定を委任しているか、計画の修正を選択しているかを確認してください。その選択を明示された範囲内で適用します。それ以外の場合は、具体的な計画上の不足を説明し、次のいずれかを選択するよう求めてください。

1. 目標実行エージェントに、確定した結果の範囲内で、最善の判断に基づいて残りの決定を解決する権限を与える。または
2. まず $interview、続いて $progress を使用して計画を修正し、その後、目標の選択をやり直す。

適用可能なユーザーの選択によってゲートを通過するまでは、目標プロンプトを出力しないでください。委任によってゲートを通過できるのは、裏付けのある結果の範囲内にある決定に限られます。委任によって成果が追加されたり、範囲が拡大されたり、外部への権限が付与されたりすることはありません。引用された計画で未決定だったというだけの理由で目標実行エージェントが再度確認を求めないよう、生成される契約の Authority フィールドにその委任を記録してください。

ユーザーが計画の修正を選択した場合、その回答は、変更を伴う別個のフェーズを明示的に求めるものとして扱います。$interview を使用して重大な決定を確定し、続いて $progress を使用して信頼できる計画文書を更新してください。その結果として得られたリポジトリの状態から現在の状態の解決をやり直し、更新後の選択フェーズは読み取り専用にしてください。計画の修正によって、すでに選択済みの範囲が消えることはありません。再検証して、その境界が新しい根拠によって大きく変わらない限り、その範囲を維持してください。境界が大きく変わる場合は、ステップ 2 に従って範囲を再度解決します。確定した結果を裏付けられない場合は、委任が利用できない理由を説明し、目標を選択する前に計画を修正するよう求めてください。

計画が十分であるか、または裏付けのある確定した結果の範囲内で残りの決定をユーザーが明示的に委任した場合にのみ、ゲートが完了します。ゲートを通過した後、ルーティングエンベロープのすべてのフィールドを確定してください。

5. 結果のルーティング

• /goal が正当化されない場合は、根拠に基づく理由を示し、プロンプトは省略します。デリバリー方式の指示は読みません。
• スコープが未確定のままである場合、またはユーザーが先に選択肢を求めている場合は、ステップ 2 の簡潔な選択肢、推奨案、選択を尋ねる質問のみを返します。デリバリー方式の指示は読まず、ゴールプロンプトも出力しません。
• スコープが選択され、証拠から/goalが正当化されることが確認され、準備状況のゲートを通過したら、prompts/delivery-variants.mdを読み、その指示に従います。
• spawnモードでは、以下のプロンプトのみを返す応答の代わりに、選択したデリバリー契約をスポーンワークフローに渡します。両方のデリバリー方式を求められても、タスクを 2 つ作成してよいことにはなりません。タスクを 1 つ作成する前に、実行するライフサイクルを確定してください。
• デフォルトでは、推奨プロンプトのみを、ラベルのない 1 つのtextコードフェンスで返します。その中には、/goalの後に入力する本文だけを記述し、フェンスの前後には文章を加えません。
• ユーザーが特定のデリバリー方式を明示的に指定した場合は、根拠に基づく推奨と異なっていても、その指定に従います。出力した方式は、そのDeliveryフィールドで示します。
• ユーザーが両方の方式を明示的に求めた場合は、2 つのtextコードフェンスでプロンプトのみを返します。それぞれのプロンプトのDeliveryフィールド内で方式を示し、両方のプロンプト本文に同一の確定済みスコープ契約を含め、デリバリーの仕組みとDeliveryフィールドだけを変えます。

応答する前に、スコープの発見と選択が読み取り専用で行われたこと、準備が許可されたフェーズ内にとどまったこと、タスクが作成されたのはスポーンが要求された場合に限ることを確認してください。選択セッションが独自のネイティブゴールや永続的なゴールファイルを作成することはありません。プロンプトを出力する場合は準備状況を確認し、要求された契約のみをコードフェンスで返してください。スポーンの場合は、スポーンワークフローに従って実際の起動状態を報告してください。