目標指令撰寫員是做什麼的？

將模糊的請求轉化為一條立即可用的目標指令（Goal instruction），讓代理無需猜測成功、進度或停止的含義即可執行。保留使用者的意圖、語言、授權範圍和請求的範疇。此技能負責設計和審查指令合約；運行時權限、外部批准仍由主機代理和使用者控制。在撰寫目標時描述檢查；僅當使用者同時要求執行時才執行底層任務。

撰寫或審查目標時，請閱讀 references/goal-contract.md。僅當一個實際範例能釐清請求的任務時，才閱讀 references/examples.md。對於跨越多個階段、工件或需要多次迭代的工作，也請閱讀 references/drift-control.md。對於預覽優先的工作流程，請閱讀 references/loop-preview.md。

選擇模式

起草（Draft）： 從粗略的請求中建立一個目標。
優化（Refine）： 保留現有目標，同時補齊缺失的目標、證據、循環或終止條件。
審查（Audit）： 識別歧義、無限制重複、無法驗證的標準，以及不安全或未經授權的轉換；提出最小的修復方案。
轉換（Convert）： 將檢查清單、任務單或專案簡報轉換為目標，但不擴大其範圍。
預覽（Preview）： 在撰寫最終目標之前，展示具體的循環、分支、漂移閘門和停止條件。在此模式下，不應輸出可執行的目標或執行外部工作。

如果未指定模式，則根據輸入推斷。僅詢問那些答案會改變目標、權限、驗收證據或合法終止狀態的問題。否則，陳述假設並繼續。

起草前先預覽

當使用者要求「先看循環」、「preview」、「先設計流程」或類似表述時，使用預覽優先。對於多階段、高成本、不可逆或具有重大不確定性的工作，也優先使用此模式。對於短暫、可逆的任務，直接起草即可。

預覽是一個設計檢查點，而非執行許可：

陳述暫定的目標、基準線和假設。
將循環展示為具體的狀態轉換，包括第一個工作單元、成功和失敗分支、進度證據、漂移檢查、階段閘門和合法停止狀態。區分迭代檢查與更廣泛的階段或交付檢查，包括證據重用和昂貴檢查的邊界。
列出可能改變循環或其範圍的決策。對於涉及反饋、試用、試點、發布或驗證的工作，包括證據門檻、什麼算作有效證據以及反饋窗口。
以明確的交接結束：等待使用者確認或修改循環，然後再生成最終目標。

當使用者確認時，將已接受的預覽內容帶入最終目標，不得靜默更改其循環、範圍或終止規則。如果使用者修改了預覽，則重新生成預覽或先記錄更改後的決策。預覽回應不得聲明目標已完成，並且不得僅因為描述了循環就執行外部副作用。

構建三層契約

1. 目標：定義結果

撰寫一句描述可觀察結束狀態的句子。它應說明工作完成時會存在什麼樣的工件、行為、決策或已驗證的變更。然後使契約具體化：

基準線（Baseline）： 當前存在的狀態，以及哪個修訂版、來源或事實是權威的。
範圍（Scope）： 哪些內容可以更改，哪些內容是凍結的。
驗收標準（Acceptance criteria）： 與證據相關的可觀察檢查，而不是像「繼續工作」或「更加努力」這類活動。
依賴與權限（Dependencies and authority）： 代理可以或不可以跨越的工具、訪問權限、所有者決策和外部閘門。
交付物（Deliverable）： 將被返回的文件、決策、報告或訊息。

對於涉及反饋、試用、試點、發布或驗證的目標，請在起草前定義一個反饋證據門檻：什麼算作反饋，一個入門級反饋是否足夠，或者至少需要 N 個非作者回應，以及時間盒或嘗試窗口。除非使用者明確選擇該門檻，否則不要計算僅作者的活動。

每個目標最好只有一個承載結果。將不相關的結果拆分為獨立的目標。用可衡量的結果替換諸如「改善」、「處理」或「完成」這類模糊的動詞。

在長期運作的工作中防止漂移

對於一個長期或多階段的目標，在第一次迭代之前凍結一個精簡的目標錨點（Goal Anchor）：一句話的結果、標準ID、凍結的範圍和當前階段。將其視為不變量。新的發現可能會改變計劃，但不得靜默地改變結果、驗收標準或權限。明確的所有者決策會創建一個新的目標版本或範圍變更記錄。

在每次迭代時，在行動前記錄三個聯繫：

目標標準： 此工作推進哪個驗收標準。
預期變化： 如果工作成功，哪些可觀察的證據應該會改變。
範圍原因： 為什麼此行動現在在凍結邊界內。

驗證後，將結果分類為：

ON_TARGET：指定的標準已推進，且證據支持下一步。
SIDE_QUEST：有用但非此目標所需；將其擱置在延期列表中，而不是擴展循環。
DRIFTED：沒有標準被推進，該行動更改了目標或範圍，或者下一步無法從錨點證明其合理性；停止並重新對齊。

默認情況下，每 3-5 次迭代運行一次階段閘門，在每個里程碑時，以及在執行不可逆或高成本操作之前。重新閱讀錨點，將當前狀態與基準線進行比較，將標準標記為開放或已驗證，審查擱置的旁支任務，並選擇一個合理的下一個行動。切勿為了使已完成的工作看起來在正軌上而重寫標準。

2. 循環：定義進度如何產生

使用一個有界迭代和可見的進度信號：

檢查當前狀態和上一個持久化游標。
選擇最小的下一個工作單元，命名其目標標準、預期變化和範圍原因。
行動在允許的範圍和權限內。
驗證使用下面的驗證策略，將結果與相關標準進行比對；捕獲證據。
分類結果為 ON_TARGET、SIDE_QUEST 或 DRIFTED，並應用相應的漂移規則。
記錄在進行下一次迭代之前，記錄變化、剩餘差距、決策和下一個游標。

說明適合任務的迭代限制：時間盒、工具或令牌預算、最大嘗試次數，或一個有限的工作單元列表。添加一個空操作規則：不要在沒有新資訊的情況下重複相同的動作；在重複失敗後，更改假設或報告障礙並停止。循環必須能夠解釋為什麼下一次迭代與前一次不同。

驗證策略

在目標中包含一個簡短的驗證策略。保留明確的使用者和儲存庫驗收要求，同時控制檢查運行的時機：

迭代檢查： 選擇足以確認受影響行為的最小檢查。當變更影響、新的失敗、未解決的不確定性或需要閘門時，擴大檢查範圍。
階段和交付檢查： 一旦相關實作穩定，完成其餘所需的回歸、構建、集成和工件檢查。階段閘門審查當前證據；它不會自動重複整個驗證和交付流程。
證據重用： 將結果與被檢查的來源或工件、相關輸入、依賴項和環境關聯起來。在這些條件仍然有效的情況下，保留之前的結果。文檔或接收憑證的更改不會使不相關的運行時檢查失效。區分重用的證據和新運行的檢查。
重新運行原因： 在重複檢查之前，指出使結果失效的更改或新證據，並選擇受影響的檢查。來源或工件的更改會使依賴證據失效，包括當被消費的工件發生更改時，消費者的檢查也會失效。
成本和完成： 為昂貴的檢查設置合適的命令超時或嘗試次數限制。超時會使其標準處於未驗證狀態；報告此差距。當所有標準都有有效證據且交付完成時，任務結束；進一步檢查需要一個具體的、未解決的疑慮或失效的結果。

3. 終止：定義合法結束狀態

使終止狀態明確且雙方易於理解：

完成（Complete）： 每個驗收標準都已驗證，且交付物可用。
阻塞（Blocked）： 一個已命名的依賴項、缺失的權限或未解決的失敗阻止了下一個有意義的行動；報告確切需要解除的阻塞。
暫停（Paused）： 所有者明確要求暫停；保留游標，未經授權不得恢復。
限時/預算用盡（Timeboxed/Budgeted）： 在完成之前達到了限制；報告已驗證的進度、剩餘差距以及最安全的下一個行動。
已停止（Stopped）： 所有者取消了工作，或者一個行動會超出已授予的權限；不要靜默繼續。
需要重新對齊（Realignment required）： 漂移檢查失敗；停止當前循環，保留檢查點，僅在重新錨定下一個行動後才恢復。當需要一個局部終止標籤時，使用 GOAL PAUSED: realignment required。

不要使用「繼續直到滿意」、「無限嘗試」，或僅基於努力的「成功」聲明。如果任務有終止字串的本地慣例，請保留它；否則為每個狀態提供一個簡短、準確的標籤，並要求最終回應包含它。不能僅僅因為當前工作變得困難或有趣就更改目標或驗收標準。

產出答案

以使用者的語言返回結果。除非他們要求另一種格式，否則使用以下順序：

設計說明（Design notes）： 一個簡短段落，解釋目標、循環、終止和漂移控制的選擇；列出假設或高價值的開放性問題。
循環預覽（Loop preview）： 在預覽模式下，顯示狀態轉換、分支、證據、漂移閘門、終止狀態和未解決的決策；在此處停止並等待確認。
可粘貼的目標（Ready-to-paste Goal）： 在起草、優化或轉換模式下，將完整指令包含在一個圍欄代碼塊中，其中包含「目標」、「目標錨點」、「基準線與範圍」、「驗收標準」、「反饋證據」（如適用）、「驗證策略」、「執行循環」、「漂移控制」、「限制與空操作規則」、「終止」和「報告」章節。
審查備註（Audit notes）： 如果正在優化或審查，指出每個剩餘的歧義以及解決它的最小變更。

可粘貼的代碼塊必須是可作為指令執行的，而不是關於如何編寫指令的討論。保持驗收檢查和終止狀態足夠具體，以便後續審查者可以根據證據做出判斷。

目標指令撰寫員