to-goal

To Goal

既存の計画とリポジトリの根拠をまとめ、実行目標を作成します。実装、トラッカーの変更、ブランチの作成、ファイルの変更は行いません。

信頼できる情報源

ユーザーが承認した計画の根拠を、会話、仕様、イシュー、文書、その他のスキルのいずれに由来するかにかかわらず、権威ある情報源として扱います。決着済みの判断を再検討しないでください。根拠が不完全な場合は、特定の計画ワークフローにユーザーを誘導するのではなく、不足している判断を明示してください。

受け付ける入力

次のいずれかを解決してください。

• 引数なし：現在の会話とリポジトリを調べ、最新の承認済みでブロックされていない作業単位を特定します。
• チケット番号または URL：そのチケットを全文読みます。
• 親仕様イシュー：仕様、サブイシュー、ブロッカーの関係を読み、現在のフロンティアを選択します。
• ローカルの仕様またはチケットのパス：ファイル全体と、直接参照されているローカルの計画文書を読みます（ローカルトラッカー：.scratch/<feature>/spec.md、およびチケットごとに .scratch/<feature>/issues/<NN>-<slug>.md のファイル）。
• --all <parent>：依存関係の順序に沿った、複数チケット横断の目標を生成します。

チケットのコメントは常に読みます。トラッカーの親チケットについて、ネイティブのサブイシュー関係と依存関係が利用できる場合はそれらを使い、利用できない場合は明示されたブロッカーの記述を使います。ラベルだけを根拠に、チケットの準備が整っていると推測しないでください。

引数なしで複数のフロンティアチケットが見つかった場合は、それらを列挙してユーザーに選択を求めます。暗黙にまとめないでください。指定されたチケットがブロックされている場合は、ブロッカーを報告し、実装目標を生成しないでください。

1 回のコンテキストで対応できない作業については、依存関係の順序を維持し、範囲を限定したフロンティア目標を 1 つ作成するか、明示的に要求された場合に限り、コンテキストをまたぐ --all 目標を作成します。特定のチケット管理スキルを必須にせず、作業の分割を提案してください。

現在の根拠を収集する

目標を作成する前に、次の手順を実施します。

1. 受け入れ基準、修正内容、直接リンクされた判断やコメントを含め、承認済みの情報源全体を読みます。
2. リポジトリの指示と、関連する設計用語を確認します。
3. 現在のブランチ、HEAD、ワークツリーの状態、最近のコミット、差分を確認します。実装前の HEAD を比較基準として記録します。
4. 現在の動作とテストを、すべての受け入れ基準と照合します。
5. 基準を「完了が根拠によって確認できる」「未完了であることが明確」「未検証」に分類します。コミットメッセージは根拠になりません。
6. リポジトリ内のスクリプト、CI、ドキュメント、既存テストから検証コマンドを確認します。
7. 情報源のコンテキストでユーザーが定めた権限とワークスペースの境界を維持します。

この作業は読み取り専用で行います。目標の作成に必要だからといって、状況記録用の成果物を作成しないでください。

範囲を選択する

既定では、ブロックされていない作業単位を 1 つだけ選択します。情報源がチケットを使っている場合は、フロンティアチケットを 1 つ選びます。生成する目標は、新しい 1 回のコンテキストで対応できる範囲に収め、後続作業を引き寄せないようにします。

--all の場合：

• 完全な依存関係の順序を維持します。
• 現在のフロンティアと今後の作業を区別します。
• 一部完了した作業は完了済みとみなさず、その状態を引き継ぎます。
• コンテキストを更新できる永続的なハーネスが必要であることを警告します。
• --all を通常の Matt のワークフローとして提示しないでください。

推奨する実行能力

ハードコードされたモデル名ではなく、必要な能力に基づいて実装セッションを分類してください。この推奨は、Claude Code、Codex、Pi、その他のコーディングエージェント間で引き継げるものでなければなりません。

能力ティアを1つだけ選択してください。

• 軽量：範囲が限定された検索、一覧作成、フォーマット、機械的な編集、または失敗時のコストが低く、確立されたパターンに沿った小規模な変更。
• 標準：通常の機能開発、対象を絞ったバグ修正、テスト、またはリポジトリ内に明確なパターンがある中程度の複数ファイル変更。これをデフォルトとします。
• 高度：難易度の高い根本原因の分析、モジュール横断の設計、セキュリティや認可の変更、スキーマやデータの移行、並行処理、長いコンテキストの統合、またはもっともらしい誤りのコストが高い作業。

推論強度を1つだけ選択してください。

• 低：曖昧さがほとんどなく、検証コストが低い決定論的な作業。
• 中：設計上の判断がある、影響するファイルが複数ある、または自明ではないテストが必要な作業。これをデフォルトとします。
• 高：動作が曖昧、相互に作用する不変条件がある、リスクの高い移行、並行処理、セキュリティ境界、または失敗時のコストが大きい作業。

選択した作業を確実に完了できる、最も低いティアと推論強度を推奨してください。根拠に基づく短い理由を1つ添えてください。作業量が多いという理由だけで強いティアを推奨しないでください。1つの新しいコンテキストウィンドウに収まらない場合は、分割を優先してください。

具体的なモデル名を挙げるのは、現在のコンテキストから対象のハーネスと利用可能なモデルの選択肢が判明している場合に限ります。モデル名を挙げるときは、推奨そのものではなく、ポータブルな推奨に続けて任意の対応付けとして提示してください。Luna、Terra、Sol などの固定されたモデル群を決して前提にしないでください。

準備状況チェックリスト

このリストはこのコンパイラー用です。貼り付けブロックには含めないでください。

必須項目 — 下書きの前にすべてにチェックを付けてください。どれか1つでも未チェックの場合は中止し、目標を作り上げないでください。

• ソースはエージェントが実行できる状態です。必要な製品上の決定事項と完了条件がすべて根拠に含まれています。そうでない場合は中止し、不足している内容を示してください。計画を決めるための聞き取りを再開してはいけません。
• 選択した作業単位にブロッカーはありません。ブロックされている場合は、ブロッカーのみを報告してください。実装目標を作成してはいけません。
• 範囲が限定された対象領域を1つだけ選択しています。同じ程度に妥当な候補が複数ある場合は、それらを列挙してユーザーに選択を求めてください。黙ってまとめてはいけません。
• 実装前のHEADを比較基準として記録しています。
• すべての受け入れ基準を「根拠により完了を確認済み」「未完了であることを明確に確認済み」「未検証」のいずれかに分類しています。
• 検証コマンドを、リポジトリのスクリプト、CI、ドキュメント、または既存のテストから確認しています。
• ソースコンテキストにある権限とワークスペースの境界を維持しています。
• すべての完了条件を、観察可能な根拠に基づいて個別に判定できます。主観的な「見た目がよい」などの条件はありません。

条件付きの禁止事項 — 単一チケットの手順ではデフォルトで満たされています。チェックを付けないでください。ここに未チェックの項目があっても中止する必要はありません。

• この実行が --all でない場合：スキップしてください。--all の場合：ユーザーが明示的に依頼しており、目標にはコンテキスト横断と明記されています。
• チケットがない作業：1つの新しいコンテキストウィンドウに収まる場合は、目標を直接作成してください。収まらない場合は、特定の計画ツールを必須とせずに分割を推奨してください。

目標テンプレート

必須項目はすべて記入してください。条件付き項目は該当する場合のみ記載してください。既知のターゲットハーネスがある場合は、その形式に合わせてください。そうでない場合は、新しいコーディングエージェントのセッションに貼り付けられるよう、この汎用ブロックを出力してください。ハーネスで指定されているセクションが少ない場合でも、現在の状態、実行順序、あらかじめ記入されている制約は必須です。

ソースのコンテキストでデフォルトの制約が明示的に上書きされていない限り、その行は一字一句変えずに維持してください。上書きされている場合は、その行を書き換え、ソースを明記してください。

現在の実装が部分的な場合は、検証済みの完了作業を現在の状態に記載し、残りの不足事項をすべて完了基準に記載してください。既知の不足事項を隠したり、次のエージェントに検証済みの作業をやり直すよう指示したりしないでください。

プロダクトに関する判断を変えずに、ソースのすべての基準を引き継いでください。完了したことが証拠で示されている作業を、未完了タスクとして再列挙しないでください。

目標

<範囲を限定した成果を1つ>

現在の状態

• ブランチ：
• HEAD（比較の基準）：
• 保護する変更済み／未追跡ファイル：
• 完了が確認できた項目：
• 既知の不足事項：
• 既存の失敗：

実行順序

<選択した作業を、依存関係に沿って最短で進める手順>

完了基準

• <ソースの基準>
• 適用可能な最小限の検証を実行した：<command>
• ソースの基準と記録済みの基準に照らして最終差分をレビューした
• 選択した基準をすべて満たし、ソースのコンテキストまたはユーザーがコミットを許可した後にのみコミットする
• このチケットの変更を除き、ワークスペースがクリーンである（無関係な変更済みファイルや未追跡ファイルには手を加えない）

制約

• プッシュ、プルリクエストの作成、マージ、イシューのクローズ、トラッカーの状態編集を行わない
• 無関係な変更済みファイルや未追跡ファイルを変更しない
• 後続作業を先行して実装しない
• 合意した検証ポイントを使い、実装の詳細より動作の証拠を優先する
• 開発中は常に、適用可能な最小限の検証を実行する
• リポジトリのゲートが要求する場合、ユーザーが明示的に依頼した場合、または変更がコアロジック、セキュリティ、データ整合性、並行処理、既知のバグの再発に影響する場合に限り、広範な検証または全検証を要求する
• 動作へのリスクが低い変更では、関連するテストポイントがない場合、またはテスト以外の検証で十分な場合に限り、テストの省略を認める。それでも適用可能な最小限の検証は必須とし、テストを省略した理由と残存リスクを実行報告に記載する
• コミット前に、ソースの基準と記録済みの基準に照らして最終差分をレビューする。利用可能なレビュー用ツールは、有用な場合にのみ使用する
• 選択した基準をすべて満たし、ソースのコンテキストまたはユーザーがコミットを許可した後にのみコミットする
• 検証の範囲：最小 | 全検証 理由：

コンテキスト

• 承認済みのソース：
• 設計ドキュメント：
• 合意した検証ポイント：
• 最初に確認するもの（コマンド／ファイル）：

提出物

次のものだけを出力してください。

1. チェック済みの準備状況チェックリスト（貼り付けブロックには含めない）；
2. 記入済みの目標テンプレート（コピーして貼り付け可能な形式）；
3. 記入済みのセッション推奨。

• セッション：fresh | persistent goal loop
• 能力：Lightweight | Standard | Advanced
• 強度：Low | Medium | High
• 理由：<観察されたタスクのリスクと複雑さに基づく1文>
• 任意のモデル対応付け：<ターゲットハーネスとそのモデルの選択肢が判明している場合のみ>

目標を直接実行する新しいセッションを推奨してください。ソース、ブランチ、記録済みの基準がコンテキストを引き継ぐため、新しいセッションに面談をやり直させたり、特定の上流スキルを必須にしたりしないでください。

--all の場合は、目標をコンテキスト横断型と明記し、継続的な目標ループを推奨してください。範囲が限定された1つの作業では、通常の新規実装セッションまたは目標ループセッションを推奨してください。ターゲットエージェントが目標をどのように実装する場合でも、目標は実行契約として機能します。推奨は特定の環境に依存しないものにしてください。たとえば、認可の移行で並行処理の不変条件がある場合は Advanced + High とし、利用可能と判明していない限り、Model X のようなモデル名は指定しないでください。