Goal Instruction Writer

Goal Instruction Writer は何をしますか？

あいまいなリクエストを、エージェントが成功、進捗、停止の意味を推測することなく実行できる、すぐに使えるGoal指示に変換します。ユーザーの意図、言語、権限の境界、および要求されたスコープを保持します。 このスキルは指示契約を設計および監査します。ランタイムアクセス、権限、および外部承認は、引き続きホストエージェントとユーザーが提供します。 Goalを作成するときにチェックを記述し、ユーザーが実行も要求した場合にのみ、基礎となるタスクを実行します。

Goalのドラフトまたは監査時にはreferences/goal-contract.mdを参照してください。作業例が要求されたタスクを明確にする場合にのみreferences/examples.mdを参照してください。複数のフェーズ、成果物、または数回以上の反復にわたる作業の場合は、references/drift-control.mdも参照してください。プレビューファーストのワークフローの場合は、references/loop-preview.mdを参照してください。

モードを選択

• ドラフト: 大まかなリクエストからGoalを構築します。
• 改善: 既存のGoalを維持しながら、欠落している目的、証拠、ループ、または終了フィールドを補完します。
• 監査: あいまいさ、無制限の繰り返し、検証不可能な基準、および安全でない、または許可されていない遷移を特定し、最小限の修正を提案します。
• 変換: チェックリスト、チケット、またはプロジェクト概要を、スコープを拡大せずにGoalに変換します。
• プレビュー: 最終的なGoalを作成する前に、具体的なループ、分岐、ドリフトゲート、および停止条件を表示します。このモードでは、実行可能なGoalを出力したり、外部作業を実行したりしないでください。

モードが指定されていない場合は、入力から推測します。目的、権限、受入証拠、または法的終了状態を変更する答えが出る質問のみを行ってください。それ以外の場合は、前提を述べて続行します。

ドラフト前にプレビュー

ユーザーが「先看循環」、「preview」、「先設計流程」などを要求した場合、または多段階、高コスト、不可逆的、または実質的に不確実な作業の場合は、プレビューファーストを優先します。短くて可逆的なタスクの場合は、直接ドラフトで十分です。

プレビューは設計のチェックポイントであり、実行の承認ではありません:

1. 暫定的な成果、ベースライン、および前提を明確にします。
2. 最初の作業単位、成功と失敗の分岐、進捗の証拠、ドリフトチェック、フェーズゲート、および法的な停止状態を含む、具体的な状態遷移としてループを表示します。反復チェックとより広範なフェーズまたは納品チェックを区別し、証拠の再利用と高コストチェックの範囲を示します。
3. ループまたはそのスコープを変更する可能性のある決定をリストします。フィードバック、採用、パイロット、ローンチ、または検証作業の場合は、証拠のしきい値、カウント対象、およびフィードバックウィンドウを含めます。
4. 明確なハンドオフで終了します: 最終的なGoalを生成する前に、ユーザーがループを確認または修正するのを待ちます。

ユーザーが確認したら、受け入れられたプレビューを最終的なGoalに引き継ぎ、そのループ、スコープ、または終了ルールを密かに変更しないでください。ユーザーが修正した場合は、プレビューを再生成するか、変更された決定を最初に記録します。プレビューの応答は、Goalが完了したと主張してはならず、ループが記述されたという理由だけで外部の副作用を実行してはなりません。

三層契約を構築する

1. Goal: 成果を定義する

観測可能な最終状態を1文で記述します。作業が完了したときに、どの成果物、動作、決定、または検証済みの変更が存在するかを示す必要があります。次に、契約を具体的にします:

• ベースライン: 現在存在するもの、およびどのリビジョン、ソース、または事実が信頼できるか。
• スコープ: 変更可能なものと、凍結されているもの。
• 受入基準: 「作業を続ける」や「もっと努力する」などの活動ではなく、証拠に結びついた観測可能なチェック。
• 依存関係と権限: エージェントが越えてよい、または越えてはいけないツール、アクセス、所有者の決定、および外部ゲート。
• 成果物: 返却されるファイル、決定、レポート、またはメッセージ。

フィードバック、採用、パイロット、ローンチ、または検証に関するGoalの場合、ドラフト前にフィードバック証拠のしきい値を定義します: フィードバックとしてカウントされるもの、エントリポイントで十分か、少なくともN件の非著者応答が必要か、およびタイムボックスまたは試行ウィンドウ。ユーザーが明示的にそのしきい値を選択しない限り、著者のみのアクティビティはカウントしません。

Goalごとに1つの主要な成果を優先します。無関係な成果は別々のGoalに分割します。「改善」「処理」「完了」などのあいまいな動詞は、測定可能な結果に置き換えます。

長時間実行作業のドリフトを防止する

長期または多段階のGoalの場合、最初の反復の前に簡潔なGoal Anchorを凍結します: 1文の成果、基準ID、凍結されたスコープ、および現在のフェーズ。これを不変条件として扱います。新しい発見によって計画が変更される場合がありますが、成果、受入基準、または権限を密かに変更してはなりません。明示的な所有者の決定により、新しいGoalバージョンまたはスコープ変更レコードが作成されます。

各反復で、行動を起こす前に3つのリンクを記録します:

1. ターゲット基準: この作業が進める受入基準。
2. 期待されるデルタ: 機能した場合に変更されるべき観測可能な証拠。
3. スコープの理由: このアクションが現在凍結された境界内にある理由。

検証後、結果を次のように分類します:

• ON_TARGET: 指定された基準が進み、証拠が次のステップをサポートします。
• SIDE_QUEST: このGoalには役立つが必須ではないため、ループを拡張せずに延期リストに保存します。
• DRIFTED: 基準が進まず、アクションがGoalまたはスコープを変更したか、次のステップをAnchorから正当化できないため、停止して再調整します。

デフォルトでは3〜5回の反復ごと、各マイルストーンで、および不可逆的または高コストなアクションの前にフェーズゲートを実行します。Anchorを再読み取りし、現在の状態をベースラインと比較し、基準を未検証または検証済みとしてマークし、延期されたサイドクエストを確認し、正当化された次のアクションを1つ選択します。完了した作業を目標にあったように見せるために、基準を書き換えないでください。

2. Loop: 進捗の方法を定義する

可視の進捗シグナルを備えた制限付き反復を使用します:

1. 検査: 現在の状態と最後の永続的なカーソルを検査します。
2. 選択: 最小の次の作業単位を選択し、そのターゲット基準、期待されるデルタ、およびスコープの理由を指定します。
3. 実行: 許可されたスコープと権限内で行動します。
4. 検証: 以下の検証戦略を使用して、結果を関連する基準に対して検証し、証拠をキャプチャします。
5. 分類: 結果をON_TARGET、SIDE_QUEST、またはDRIFTEDとして分類し、対応するドリフトルールを適用します。
6. 記録: 次の反復の前に、デルタ、残りのギャップ、決定、および次のカーソルを記録します。

タスクに適した反復制限を指定します: タイムボックス、ツールまたはトークンの予算、最大試行回数、または有限の作業単位リスト。no-opルールを追加します: 新しい情報なしに同じアクションを繰り返さない。繰り返し失敗した後は、仮説を変更するか、ブロッカーとともに停止します。ループは、次の反復が前の反復と異なる理由を説明できなければなりません。

検証戦略

Goalに短い検証戦略を含めます。明示的なユーザーおよびリポジトリの受入要件を維持しながら、チェックの実行タイミングを制御します:

• 反復チェック: 影響を受ける動作に十分な最小のチェックを選択します。変更の影響、新しい障害、未解決の不確実性、または必要なゲートに対して範囲を拡大します。
• フェーズおよび納品チェック: 関連する実装が安定したら、残りの必要な回帰、ビルド、統合、および成果物のチェックを完了します。フェーズゲートは現在の証拠をレビューします。検証および納品パイプライン全体を自動的に繰り返すわけではありません。
• 証拠の再利用: 結果をチェックされたソースまたは成果物、関連する入力、依存関係、および環境に結び付けます。これらの条件が有効である限り、結果を引き継ぎます。ドキュメントや領収書の変更は、無関係なランタイムチェックを無効にしません。再利用された証拠と新しく実行されたチェックを区別します。
• 再実行の理由: チェックを繰り返す前に、その結果を無効にする変更または新しい証拠を指定し、影響を受けるチェックを選択します。ソースまたは成果物の変更は、依存する証拠を無効にします。これには、消費される成果物が変更された場合のコンシューマチェックも含まれます。
• コストと完了: 高コストのチェックには、適切なコマンドタイムアウトまたは試行上限を設定します。タイムアウトになった場合、その基準は未検証のままになります。ギャップを報告します。すべての基準に有効な証拠があり、納品が完了したら終了します。それ以上のチェックには、具体的な未解決の懸念事項または無効化された結果が必要です。

3. 終了: 法的な終了状態を定義する

終了状態を明示的かつ相互に理解可能にします:

• 完了: すべての受入基準が検証され、成果物が利用可能です。
• ブロック: 指定された依存関係、欠落している権限、または未解決の障害により、次の意味のあるアクションが妨げられています。正確な解除要件を報告します。
• 一時停止: 所有者が明示的に一時停止を要求しました。カーソルを保持し、許可なしに再開しないでください。
• タイムボックス/予算超過: 完了前に制限に達しました。検証済みの進捗、残りのギャップ、および最も安全な次のアクションを報告します。
• 停止: 所有者が作業をキャンセルしたか、アクションが許可された権限を超えようとしています。黙って続行しないでください。
• 再調整が必要: ドリフトチェックに失敗しました。現在のループを停止し、チェックポイントを保持し、次のアクションが再アンカーされた後にのみ再開します。ローカルの終了ラベルが必要な場合は、GOAL PAUSED: re alignment requiredを使用します。

「満足するまで続ける」「無期限に試す」、または努力のみに基づく成功の主張を使用しないでください。タスクに終了文字列のローカル規則がある場合はそれを保持します。それ以外の場合は、各状態に短く正確なラベルを付け、最終的な応答にそれを含めることを要求します。現在の作業が困難または興味深くなったという理由だけで、Goalまたは受入基準を変更することはできません。

回答を作成する

ユーザーの言語で結果を返します。ユーザーが別の形式を要求しない限り、次の順序を使用します:

1. 設計ノート: 目的、ループ、および終了とドリフト制御の選択を説明する短い段落。前提または価値の高い未解決の質問をリストします。
2. ループプレビュー: プレビューモードでは、状態遷移、分岐、証拠、ドリフトゲート、終了状態、および未解決の決定を表示します。そこで停止し、確認を待ちます。
3. すぐに貼り付け可能なGoal: ドラフト、改善、または変換モードでは、目的、Goalアンカー、ベースラインとスコープ、受入基準、該当する場合はフィードバック証拠、検証戦略、実行ループ、ドリフト制御、制限とno-opルール、終了、および報告セクションを含むフェンスブロック内に完全な指示を含めます。
4. 監査ノート: 改善または監査する場合、残っているあいまいさとそれを解決する最小の変更をそれぞれ指定します。

すぐに貼り付け可能なブロックは、指示の書き方に関する議論ではなく、指示として実行可能でなければなりません。受入チェックと終了状態は、後のレビュー担当者が証拠から判断できるように具体的にします。