目標定義 (Define Goal)

目標定義 (Define Goal) は何をしますか？

概要

ユーザーの意図を、スコープが限定され、リクエストから導かれる完了根拠を持つ具体的な成果に整形します。通常の検証では、メインプロンプトのルールに従って読み取りと論理的評価を使用します。数値は、実際の要件を表す場合にのみ使用します。

このスキルは、目標定義とGoalツールの作成のみをカバーします。このスキルから中間計画成果物、永続的なスナップショット、台帳、決定ログ、再開ファイルを作成しないでください。

ルートのMainのみがネイティブGoalを管理します。その選択により、テスト、レビュー、委任、権限、その他のワークフローは追加されません。Gold Standardは、Goalの有無にかかわらず、有用な作業状態を独立して評価します。Notebookは、別の手動リクエストなしに、独自の条件の下で選択されたGoalに自動的に参加する場合があります。Goalだけではそれを必要としません。そのポリシーの下で、この定義手順の外で、有用な運用ノートを保持します。ネイティブの目的とステータスは引き続き信頼できます。

定義だけでは、提案されたタスクの実行を許可しません。Goalが必要な承認または実行確認を置き換えることは決してありません。ToSpecの準備は将来の実行Goalを開始しません。明示的に選択された準備Goalは、要求された準備結果のみに関するものです。自動選択は、ユーザーの一時停止を上書きしたり、ブロッカー、承認待ち、ターン終了、または破棄なしのキャンセルを完了に変えたりしません。実際のネイティブステータスルールに従ってください。完了には、実際の結果と既に必須のアクションすべてが必要です。

ワークフロー

1. Goalが実際の現在の指示に対して有用かどうかを評価します。

   • 独立して依頼された成果が、依存する段階、実質的な調査または不確実性、または長時間の実行を必要とする場合、ステップ6の権限チェックに従い、自動的に選択します。
   • 短い質問、簡単な編集、将来の作業の議論にはGoalは不要です。依頼された発見自体は具体的な成果を持ち得ます。それについて議論しても、実行を許可するわけではありません。
   • 直接の/goal、Goal作成リクエスト、または目標定義リクエストは、複雑さに関わらずこのスキルを選択します。Goalなしで作業する指示は、影響を受けるタスクの自動選択よりも優先されます。
   • すべてのツール呼び出しではなく、タスクの重要な変更後に再評価します。コマンド、分数、ファイルのしきい値は使用しません。

2. 可能性のある目標を具体的な用語で言い直します。 使用可能なGoalは以下を指定します：

   • 真となる具体的な成果
   • 関係する主要なアーティファクト、システム、リポジトリ、環境、またはユーザー向けの振る舞い
   • 読み取りと論理的評価、および明示的に要求された証拠によって、実際の結果がどのように確立されるか
   • スコープ内のもの
   • あいまいさが問題になる場合のスコープ外のもの
   • 行き詰まる代わりにユーザーに尋ねるための停止条件

3. 要求された結果を表す基準を使用します。

   • 成果、アーティファクトパス、スコープ、形式、値、バイナリ完了条件をリクエストから導き出します。
   • 形式的な測定可能性のために、メトリクス、しきい値、バリデータ、実行回数を発明しないでください。
   • テスト、コマンド、CI、測定、証拠カウントは、明示的に要求された経験的証拠、または特別に採用された手順や優先度の高い義務がある場合のみオプションです。
   • 通常の修正、分析、またはアーキテクチャベースのパフォーマンス作業では、実際の結果と論理的評価によって完了を定義します。

4. 弱いGoalを設定する前に修正します。

   • 要求とローカルコンテキストがその解釈を安全にする場合、曖昧なGoalを具体的な成果基準に書き換えます。
   • 不足している詳細が意図された成果や検証を変更する場合、簡潔な明確化の質問を1つ行います。
   • 「進捗を出す」「調査を続ける」「改善する」「Xに取り組む」のような純粋な活動目標は、検証可能な成果に具体化されない限り拒否します。

5. Goalを作成する前にアクティブなGoalの状態を確認します。

   • scope_focus_native_contextから現在のルートネイティブGoalスナップショットを読み取ります。conversationId、goalId、objective、ネイティブステータス（0：未指定、1：アクティブ、2：一時停止、3：完了、4：クリア）を検証します。有効なルート状態がない場合はGoalなしを意味します。不明なID/状態は存在しないのではなく不明です。子はルートGoalを管理しません。指定されている場合のみ実際のネイティブ予算フィールドを使用し、発明しないでください。
   • 利用可能なネイティブのcreate_goal/update_goalツールとその現在のスキーマを使用します。Cursorのcreate_goalはobjectiveを受け取ります。Codexのみの予算フィールドを渡さないでください。必須のネイティブ機能がない場合、その依存する遷移は停止します。Goalをシミュレートしたり、完全な準備ができていると主張しないでください。
   • 未完了のGoalがなく、objectiveが品質基準を満たし、ステップ6が作成を許可する場合、create_goalを呼び出します。
   • 現在のユーザー指示とネイティブ状態に従って、一致する未完了のGoalを再利用します。繰り返し選択しても、重複を作成したり、完了した操作を繰り返したりしません。
   • 競合する未完了のGoalを維持します。場所を確保するためだけにリセット、置き換え、または完了とマークしないでください。許可されたネイティブパスまたは焦点を絞ったユーザー質問を通じて、重要な競合のみを解決します。新しいスレッドを必要としません。

6. 品質基準を満たした場合のみGoalを作成します。

   • このスキルを選択しても、それ自体でcreate_goalが許可されるわけではありません。実際のツールの指示と優先順位の高いルールに従ってください。条件付き自動Goalのユーザー採用、または該当するシステム/開発者指示の明示は、それらのルールが受け入れる場合のみ、常設のリクエストを提供します。スキルの可用性や通常のタスクだけではその権限ではありません。ホストが別個の明示的なリクエストを必要とする場合、その要件に反して許可を推測しないでください。
   • ネイティブGoalが利用不可または許可されていない場合、ファイルや別のコントローラでシミュレートしないでください。互換性のある承認された作業を継続します。結果または明示的に要求されたGoalに重要な場合のみ、具体的な制限を開示します。
   • 単一の簡潔なobjective文字列を使用します。
   • 完了の十分な根拠を含めます：読み取りと論理によって評価された要求された結果、および明示的に必須の証拠。追加されたすべてのしきい値や方法はリクエストに従う必要があります。objectiveに書き込んでも権限は生まれません。
   • スコープ境界が作業を制約する場合、それらを含めます。
   • 予算は、明示的に要求され、実際のネイティブスキーマでサポートされている場合のみ提供します。要求された予算をCursorネイティブGoalで表現できない場合、その依存する遷移を停止し、欠落している機能を開示します。黙って破棄したり、予算をシミュレートしたりしないでください。
   • モードを有効にしたり、技術的な文言を承認したりするためだけに再度尋ねることなく、明確な許可されたGoalを定式化します。不足している選択が要求された結果、権限、または必須の証拠を実質的に変更する場合のみ尋ねます。定義のみのリクエストは定義のみのままです。

Goal品質基準

create_goalの前に、objectiveは以下に答える必要があります：

• これが完了したとき、具体的に何が真になるのか？
• それを確立する実際の材料と論理的根拠は何か、ユーザーが明示的に要求した経験的証拠は何か？
• 成功を定義する要求された成果または意味のあるバイナリ/定量的条件は何か？
• どのスコープ境界が重要か？
• 何がエージェントを停止させ、尋ねさせるべきか？

良い例：

指定された設定でAをBに置き換えます。編集が存在し、影響を受けるコードを読むことでリクエストとの一貫性が確立されたときに完了します。

良い例：

関連するソースとロジックから指定された設計上の質問を解決します。結論が支持され、実質的な矛盾が対処されたときに完了します。

弱い例：

チェックアウトを高速化します。

弱い例：

PRのコメントを調査し続けます。

定量化のヒューリスティック

• バグの場合、必要な修正を定義し、影響を受けるコードとロジックを通じて説明します。再現と失敗→成功のバリデータには、その証拠の明示的なリクエストが必要です。
• 明示的に要求されたテストの場合、順序付けられたシナリオとその合格条件を指定し、指定されたコマンドを尊重します。
• パフォーマンスの場合、メカニズム、作業、コンテキストから推論します。計算された複雑性は計算としてラベル付けします。実際の測定からのみ測定された改善を主張します。メトリクス、ターゲット、方法、実行回数を発明しないでください。
• 品質作業の場合、要求された成果を使用し、通常は読み取りとロジックを通じて評価します。lint、型チェック、テストを自動的に追加しないでください。
• 調査の場合、調査が可能にしなければならない決定、スコープ内のソースまたはシステム、および証拠基準を定義します。
• 運用の場合、要求された結果の状態を定義します。監視ウィンドウ、しきい値、ロールバック作業を発明しないでください。

明確化の質問

合理的な書き換えが間違った成果を追求するリスクがある場合のみ質問します。質問は短く、不足しているバリデータやスコープ境界を中心にします。

有用な質問の形：

• 「ここでの成功を定義するメトリクスは何ですか：レイテンシ、コスト、精度、またはユーザーに見える振る舞い？」
• 「どの環境に対して検証すべきですか：ローカル、ステージング、本番？」
• 「このGoalを完了とマークする前に、どの最小限の証拠が必要ですか？」

意味のある基準がリクエストから直接導かれる場合、再度確認せずに定式化します。未解決の選択が結果または必須の証拠を実質的に変更する場合のみ質問します。