write-goal

提供されたソースを、4,000 文字以内の単独の目標にまとめてください。この目標がソースに置き換わります。この目標に基づいて作業するエージェントは、ソースもこの会話も持たないため、目標から抜け落ちた義務は失われ、目標が新たに定めた要件は拘束力を持ちます。

ソース。 マニフェスト — 提供する成果物、完了とみなす条件、全体を通して適用される制約を定めたもの。調査結果 — 会話またはログファイルに記された、根拠と、それを覆す条件を伴う明示的な結論。チケット、引き継ぎ、簡潔な依頼、またはそれらの複数の組み合わせ。依頼または会話で指定されたソースを使用してください。対象が不明または曖昧な場合は、どのソースか確認してください。すべてのソースと、その意図や要件を理解するために必要な参照資料を読んでください。明示されたユーザーによる修正を反映し、確定した決定と、まだ検討中の提案を区別してください。

各ソースが引き継ぐべき内容：

• マニフェスト： Outcome と、現在のすべての Acceptance Criterion および Global Invariant を、それぞれの主張の権限を保ったまま引き継ぎます。ハードな主張とは、意図的に明示されたユーザー要件、または適用されるプロジェクト上、安全上、権限上の義務です。変更できるのは、そのソースで許可されている場合のみです。作業上の主張とは、エージェントが運用のために解釈した内容であり、Outcome とハード要件を維持する限り、根拠に応じて変更できます。この裁量も、現在の目標とともに引き継いでください。根拠を得る方法は、ハードな主張が明示的に要求していない限り、作業上のものです。レビュー結果を実行者が根拠に基づいて判断できるのか、それとも意図的に閾値や承認が求められているのかを保ってください。処置を決める権限が付与されている場合は、その判断を裏付ける根拠を記録する義務も引き継ぎます。実際に満たされていない主張や重要な不確実性は、未解決のまま残してください。根拠、プロセスの指針、初期アプローチは、新たな要件を追加しません。計画全体の承認によって、作業上の選択がハードな主張に変わることはありません。権限の欠如はソースの不備であり、以前の契約を再分類する許可ではありません。
• 調査結果： 結論、意図する結果、確定した要件、提案された評価方法を、ハードなものと作業上のものの区別を保って引き継ぎます。除外された調査分岐と、後続作業を許可なく除外することを区別してください。引き継ぐのは後者だけで、納品範囲の制限とします。根拠、対立する説明、覆る条件、受け入れられていない提案は、要件ではなく判断材料です。
• その他のソース： 確定した決定を引き継ぎます。まだ検討中の提案に従う義務はありません。

列挙する前に不足を確認してください。 ソースには、次の4点が定まっていなければなりません。

1. 完成時の成果。
2. 目標だけを読む人が、完了か未完了かを判断できる完了確認方法。
3. 範囲と除外事項。
4. 作業の停止地点。完了確認方法が作業の終わりを示す場合、またはソースが停止地点を明示している場合は、停止地点が定まっています。取り消せない行為や、誰かの承認が必要な行為（マージ、デプロイ、送信、支出など）に進む可能性があり、実行するかどうかをソースが定めていない場合は、依然として不足しています。マージするかどうかを示さず、プルリクエストの作成で終わるソースでは、停止地点は未確定です。

目標の作成前に、目標を実質的に変える不足や矛盾をすべて解消してください。決して推測で補ってはいけません。不足が明確な質問1つで解消できる場合は、ユーザーに直接尋ねてください。一度に質問は1つとし、それぞれ短い回答1つで解決できるようにしてください。質問するのは、上記の未解決項目に限ります。調査が必要な不足、またはまだ明確な質問1つにできない不足がある場合は、figure-out スキルを呼び出します。上記の未解決項目を「目標のためにこれらを解決し、調査結果を返す」という課題として渡し、返された調査結果をソースに加えたうえで、再度確認してください。figure-out スキルを利用できない場合は、その旨を伝えて不足について質問するか、目標を作成せずに停止してください。 ドラフトの前に、ゴールが果たすべきことを列挙します。 上記のように、ソースが求める義務をすべて書き出し、ソースに記載された適用範囲の制限、除外事項、停止条件、承認の境界もすべて書き出します。ユーザーの修正で削除されたものは除きます。複数の要件を一つのチェックで確認できる場合は、各要件の条件がすべて保たれる範囲でのみ、一つにまとめられます。項目を削除したり弱めたりせずにリストを4,000文字以内に収められない場合は、ドラフトの前に、どの項目を削るかユーザーに確認します。

リストをもとにドラフトを作成します。 冒頭に完成した成果を示し、その後、各項目の効力を平易な言葉で保ちます。何を満たす必要があるか、証拠に基づいて何を修正できるか、何が単なる助言かを明確にします。ID、ワークフロー用語、ソースへの参照、ソースのワークフローに依存する手順は使いません。解釈の指針となる目的と根拠、境界を明確にする例、条件付きの前提は保ちます。完了には、意図した結果と、観察された証拠に基づく現在のチェックが必要です。また、ソースで求められている範囲を限定したビルド作業があれば、それも完了している必要があります。代替指標に合格しただけでは不十分です。重要な作業上の修正について説明し、影響を受ける証拠を更新します。提示された割り当ての一部として継続状態が含まれる場合は、裏付けのある判定と、それを再検討する条件を保ちます。ソースで成功条件として指定されている場合は、具体的なコマンド、スキル、成果物名を含めることができます。実行戦略はエージェントに委ねます。ソースで指定されていない指標、予算、レポート形式、レビュー手順、ポリシーを追加せず、既知の適用先にすでに備わっているポリシーは省きます。スペースと句読点を含めてゴールの文字数をプログラムで数え、4,000文字以内になるよう修正します。上限を目標にしてはいけません。

初見で読んでも分かるか確認します。 新しいコンテキストにゴールだけを渡し、このファイルのパスをゴールの基準として示します。そのコンテキストにはレビューだけをさせ、ドラフトの作成はさせません。そして、ゴールに従うと何を作ることになるか、どのような制限が設けられているか、何をもって完了と判断するかを尋ねます。続いて、ソースをテキストとして渡します。Manifest のファイル、read のテキストとそのログパス、会話内にしか存在しないソースについては、ユーザーが確定したメッセージの引用を渡します。さらに、ユーザーの修正内容とリストも渡し、リストを検証対象の主張、ソースをレビュー対象ではなく基準として扱うよう伝えたうえで、ソースからゴールが果たすべきことを導き出すよう依頼します。次の点をそれぞれ報告するよう求めます。ゴールで削除または弱められた義務、ソースにない要件、作業上の選択が固定された箇所、確定的な主張が修正可能なものにされた箇所、レビュー評価が拒否権に格上げされた箇所または明示的に求められた承認が削除された箇所、与えられた判定の処分権限が失われた箇所、ソースでは義務付けられていない助言（方法、計画、提案など）が要件として記された箇所、削除または置き換えられた範囲をゴールが復活させた箇所、ソースまたはその ID への参照、ソースでは判断できるのにゴールだけを読んだ人には完了か未完了かを判定できない条件、そしてソースで指定された各チェックについて、そのチェックなら検出できるのにゴールでは見逃す可能性がある誤った結果。ソースに Manifest がない場合は、ゴールが契約としてまだ誰にもレビューされていないため、指定された範囲内では同時に満たせない条件と、見落としをゴール内のどのチェックでも検出できず、その見落としがあってもすべてのチェックに合格してしまう要件の欠落、または結果が欠けているのに現状ですでに合格してしまうチェックも併せて尋ねます。ゴールに記載されたコマンドを実行し、その出力を読むことで読者が直接判断できる要件は、判断可能です。すべての指摘を一度で解決します。修正するか、理由を添えて却下してから、ゴールの文字数をもう一度数えます。ソースから判断できない指摘はギャップです。創作で埋めず、上記の方法で補います。修正するとゴールが4,000文字を超える場合は、ユーザーに削る項目を尋ねます。レビューは二度目を行いません。分離したコンテキストを利用できない場合は、ゴールを先にして、同じ二つの読み取りを自分で行います。 目標を、プレーンテキストのコードフェンス内に1つの段落として記述してください。フェンスの下には、指摘事項を却下した場合はその内容と理由を記した短い注記を1つだけ追加し、レビューを自己評価した場合も短い注記を1つだけ追加してください。それ以外の場合は、フェンスのみを返してください。この呼び出しでは文章の草案を作成するだけです。ソースの編集、実行中の目標の設定、または説明されている作業の開始は行いません。