define-goal

目標を定義する

概要

ユーザーの意図を、エージェントが誠実に取り組める目標に落とし込みます。作業内容の説明よりも、測定可能な成果、明示的な証拠、明確なスコープを優先します。

このスキルの対象は、目標の定義と目標ツールの作成のみです。このスキルを使って、中間計画の成果物、永続的なスナップショット、台帳、意思決定ログ、再開用ファイルを作成しないでください。

ワークフロー

1. 目標の定義が本当に必要か確認します。

   • ユーザーが $define-goal を求める、目標の作成や設定を依頼する、目標ツールを求める、または意図を明確な目標にする支援を求める場合は、このスキルを使います。
   • ユーザーが通常の実装作業のみを依頼している場合は、目標の作成を無理に求めず、直接作業します。

2. 想定される目標を具体的な言葉で言い換えます。 実用的な目標には、次の要素が含まれます。

   • 達成時に実現している具体的な成果
   • 関連する主要な成果物、システム、リポジトリ、環境、またはユーザー向けの動作
   • 完了を検証する方法
   • 対象範囲
   • 曖昧さが問題になる場合は、対象外の範囲
   • 作業を続けるのではなく、ユーザーに確認するための停止条件

3. 対象分野に適している場合は、定量的な目標にします。 見せかけの精密さではなく、実際の成功を示す数値を優先します。

   • 合否を判定するバリデーター：具体的なテスト、チェック、CI ジョブ、評価、コマンド、または受け入れ基準
   • 品質のしきい値：レイテンシ、エラー率、コスト、精度、再現率、適合率、カバレッジ、不安定なテストの割合、バンドルサイズ、メモリ、稼働率、完了率、または手動レビューの基準
   • 成果物の制約：ファイルパス、影響を受けるモジュール、許可されたコマンド、出力形式、対象環境、期限、または最大の影響範囲
   • 証拠の件数：再現した失敗、成功した再実行、レビューした事例、移行したレコード、対応したコメント、または検証したケースの数

4. 弱い目標は、設定する前に改善します。

   • ローカルの文脈から安全に言い換えられる場合は、曖昧な目標を測定可能な目標に書き換えます。
   • 不足している詳細によって意図する成果や検証方法が変わる場合は、簡潔な確認質問を1つします。
   • 「進捗を出す」「調査を続ける」「改善する」「X に取り組む」といった、作業そのものを目標とする内容は、検証可能な成果に具体化できない限り受け付けません。

5. 目標を作成する前に、有効な目標の状態を確認します。

   • get_goal を呼び出します。
   • 有効な目標がなく、目標が品質基準を満たしている場合は、create_goal を呼び出します。
   • 有効な目標がユーザーの意図と一致している場合は、重複して作成せず、その目標を引き続き使用します。
   • 有効な目標が新しい依頼と矛盾する場合は、現在の目標を完了するか、完了済みとしてマークするか、別の目標に基づくスレッドを開始するかを尋ねます。

6. 品質基準を満たした後にのみ目標を作成します。

   • 簡潔な目標文を1つ使います。
   • 検証に使う証拠を目標文に含めます。
   • 作業を制約する場合は、スコープの境界を含めます。
   • トークン予算は、ユーザーが明示的に求めた場合にのみ含めます。
   • ユーザーが目標に基づく作業を明示的に依頼していない限り、通常の複数ステップのタスクに対して create_goal を呼び出さないでください。

目標の品質基準

create_goal の前に、目標が次の問いに答えていることを確認します。

• 完了時に実現している具体的な状態は何ですか？
• それを証明する証拠は何ですか？
• 成功を定義する定量的または二値のしきい値は何ですか？
• 重要なスコープの境界は何ですか？
• どのような状況でエージェントは停止して確認すべきですか？

良い例：

ドキュメント化された低速パスにおけるチェックアウト API の p95 レイテンシを 250 ms 未満にします。安全性を保てる最小限のサーバー側変更を行い、npm run test:checkout と既存のローカルレイテンシベンチマークを使って、3 回連続で p95 が 250 ms 未満であることを確認します。

良い例：

PR 123 でコード変更を求める未解決のレビューコメントに対応します。変更対象は、影響を受ける認証関連ファイルとテストに限定します。対象を絞った認証テストコマンドを実行し、gh pr view 123 で変更要求の未解決スレッドがないことを確認します。

弱い例：

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

弱い例：

PR のコメントを引き続き調査する。

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

• バグの場合は、まず再現を成功条件とし、次に修正、可能であれば失敗から成功に変わるバリデーターを定義します。
• テストの場合は、正確なコマンドと合格に必要な条件を明記します。
• パフォーマンスの場合は、指標、目標しきい値、測定方法、実行回数を明記します。
• 品質改善の場合は、レビュー済みの例、lint／型チェック／テストの合格、ユーザー承認済みの成果物など、観測可能な合格基準を定義します。
• 調査の場合は、調査によって可能になる意思決定、対象となる情報源やシステム、証拠の基準を定義します。
• 運用の場合は、正常な状態、監視期間、障害しきい値、ロールバックまたはエスカレーションのトリガーを定義します。

確認の質問

妥当な書き換えをしても、誤った成果を追求してしまうおそれがある場合に限り、質問します。質問は短くし、不足しているバリデーターまたは対象範囲の境界に焦点を当てます。

質問の例：

• 「ここで成功を定義する指標はどれですか？レイテンシ、コスト、精度、ユーザーに見える動作のいずれでしょうか？」
• 「どの環境で検証すればよいですか？ローカル、ステージング、本番のいずれでしょうか？」
• 「この目標を完了とするために、最低限必要な証拠は何ですか？」

ユーザーが指標を提示できない場合は、最も誠実に設定できる二値のバリデーターを提案し、確認を求めます。