實作任務
交付一個 1 點的 PR 供審查，內容完全符合任務要求，不多也不少。
輸入
$ARGUMENTS
- Ticket，必要：一個追蹤器金鑰（例如
ENG-123）或本機 ID（例如T-04）。如果未提供，請列出待辦任務（狀態為open，相依項目已合併），以關鍵路徑優先，並詢問要處理哪一個。在無人值守模式下，改回報blocked。 --tasks <file>：本機任務檔案。若未指定，請在專案本機、被 git 忽略的 RFC 資料夾（例如.rfcs/）中尋找包含該任務的*.tasks.md，然後是docs/rfcs/。--base <branch>：起始分支及 PR 的目標分支。預設為 main。非 main 的分支代表此 PR 是堆疊在另一個尚未合併的 PR 上。--branch <name>：使用的分支名稱。否則遵循步驟 1 的命名規則。--feedback <pr>：不實作；改為處理現有 PR 的審查意見（請參閱最後一節）。--unattended：你由協調者啟動，沒有人能回答問題。不要提問；當你想提問時，停止並在報告中說明。在你的工作樹中完成工作。
任務與本機檔案的位置
- 優先使用追蹤器。 如果任務有追蹤器金鑰（來自參數或任務檔案的
Tracker:欄位），請透過已連接的追蹤工具（Linear、Jira、GitHub Issues 等）擷取。發佈後，追蹤器是任務內容的唯一真相來源；如果任務已被取消或標記為完成，請停止並回報。 - 否則使用本機任務檔案，以及追蹤器問題缺少的欄位（檔案、超出範圍等）。RFC 和任務檔案是開發人員的本機、未追蹤文件，因此只存在於主專案資料夾中，而非工作樹中。如果你在工作樹中，請使用
git worktree list（第一個條目）找到主資料夾，並透過絕對路徑讀取其中的檔案。將主資料夾視為唯讀：切勿編輯、檢出或在其中執行 git 命令。 - 切勿提交 RFC、筆記或任務檔案。透過明確路徑暫存檔案，而非使用
git add -A。
1. 選擇任務
- 閱讀任務（見上文），包括其驗收標準和相依項目。如果其類型為
spike，請停止：spike 產出的是決策，而非 PR；請指向/spike-task（無人值守：回報blocked）。 - 當相依項目的 PR 已合併到 main（使用
gh檢查 PR 狀態，或檢查相依項目的狀態pr-merged/done），或當基底分支是該相依項目自己的分支（堆疊）時，該相依項目即視為已滿足。Spike 相依項目僅在其狀態為done時才算滿足，表示其決策已獲批准且待辦事項已完善。如果有任何相依項目未滿足，請停止並說明是哪一個。 - 確保工作目錄乾淨，進行 fetch，並從最新的
origin/<base>建立分支。 - 分支名稱（除非已使用
--branch指定）：<username>/<project-slug>/<task-branch>。username：如果使用者的現有分支遵循此模式，則取其前綴；否則取其 GitHub 登入名稱（gh api user --jq .login）。project-slug：來自任務檔案的Project slug:標頭，或 RFC 名稱的 kebab case 形式。task-branch：追蹤器金鑰加上一個簡短的 slug，例如eng-123-add-v2-flag（金鑰可讓追蹤器整合連結 PR），如果是未發佈的任務則為t-04-add-v2-flag。
- 如果你直接與使用者（非無人值守）合作，請在任務檔案中，以及在其 GitHub 整合不會自動處理的情況下也在追蹤器中，將任務狀態設為
in progress。
2. 僅載入任務需要的內容
閱讀任務、它所依賴的 RFC 章節，以及它命名的檔案。然後追蹤實際流程：呼叫者、現有輔助函式，以及你將變更的程式碼旁邊的測試。閱讀足夠的內容以完全理解問題，但不要載入整個 RFC 或對話歷史；任務的設計應能獨立存在。如果不能，這是一個需回報的空白，而非猜測的理由。
3. 先撰寫測試
將每個驗收標準轉換為測試，使用儲存庫現有的測試框架、位置和風格。執行它們並確認它們因正確的原因而失敗。每個標準一個重點測試就足夠：除非現有模式要求，否則不要新增新的測試工具、fixture 或輔助函式。純機械性的任務（例如新增一個旗標）可能不需要新測試，如果該標準已由現有測試或型別檢查器檢查；請在 PR 中說明。
4. 實作最小的完整變更
「完整」表示每個驗收標準都通過。「最小」表示只做這些，不做更多。這遵循 ponytail 方法；如果已安裝 ponytail 技能，請立即以其預設等級載入，並讓它主導此步驟。
否則，選擇第一個可行的選項：
- 需求是否已滿足？如果現有程式碼已滿足標準，請停止並建議關閉任務。
- 重複使用程式碼庫中已有的內容：輔助函式、型別、模式。
- 使用標準函式庫，然後是原生平台功能（資料庫約束、內建 HTML 輸入、CSS 優先於 JavaScript），最後是已安裝的相依套件。
- 只有到那時才編寫新的程式碼，越少越好。
撰寫時：
- 不做投機的結構。 沒有只有一個實作的介面、沒有一個產品的工廠、沒有永不變更的值的設定、沒有「為將來準備」的鷹架。優先編輯現有檔案而非建立新檔案。
- 符合周圍程式碼風格：命名、錯誤處理、結構。diff 看起來應該像是程式碼庫自己寫出來的。
- 只在程式碼無法表達時加入註解。 不要敘述程式碼做什麼、不要重述任務、不要留下註解掉的程式碼或除錯輸出。唯一值得加入的註解是當你刻意簡化時：指出限制以及何時升級，這樣就不會有人不小心「修正」它。
- 從根源修復錯誤。 在變更共用函式前，檢查所有呼叫者。
- 絕不降低安全性。 信任邊界的輸入驗證、防止資料遺失的錯誤處理、安全性與無障礙基本原則始終正確執行，即使任務沒有明確說明。
5. 守護範圍
如果任務實際上超過 1 點（超過大約一天、出現第二個關注點、或某個標準在沒有觸及無關區域的情況下無法達成），請停止。不要提交任何超出乾淨狀態的內容，解釋你發現了什麼，並提出拆分為新任務的建議供批准：與使用者合作時寫入任務檔案，無人值守時寫入報告。你注意到的無關問題應寫入 PR 的備註，而非 diff。切勿弱化或重新解釋驗收標準以使其通過。
6. 驗證並開啟 PR
- 按照儲存庫的方式執行測試、linter 和型別檢查器。如果變更具有執行時期行為且你可以執行
/verify，請執行；否則使用專案自己的執行或檢查命令來驗證行為。 - 自己重新閱讀完整的 diff：每一行變更都應追溯到一個驗收標準。移除無關的格式調整、重新命名和遺失的檔案，並確保沒有本機 RFC 或任務檔案混入。
- 按照儲存庫的提交風格提交，推送，並針對基底分支開啟準備好審查（非草稿，以便審查自動化執行，除非使用者要求草稿）的 PR，使用 templates/pr.md。在標題中放入追蹤器金鑰，並在描述中連結追蹤器問題。如果基底不是 main，請說明它堆疊在哪個 PR 上，以及該 PR 需要先合併。如果你無法從此處開啟 PR，請推送分支並在回覆中包含 PR 文字。
- 如果你直接與使用者合作，請將任務狀態設為
pr-open（或pr-draft），並在任務檔案中填入Branch / PR:，且如果其 GitHub 整合不會自動處理，則將追蹤器問題移至審查狀態。無人值守時，將狀態留給協調者處理。 - 以下面的報告結束。如果有使用者存在，兩三行的版本就足夠了。
處理 PR 審查意見（--feedback）
你得到一個 PR 和一份待處理的審查項目清單（評論連結及應做事項）。
- 在你的工作樹中 fetch 並檢出該 PR 的分支。閱讀任務和項目；閱讀當前的 diff。
- 以能解決問題的最小變更處理每個項目，遵循步驟 4 的相同規則。保持在任務的範圍內：如果某個項目要求的內容超出範圍，不要實作；將其回報為後續事項。
- 使用新的提交而非修改或強制推送，以便審查者可以看到自他們審查以來的變更。執行測試，然後推送。
- 在每個已處理的評論討論串回覆一行，說明變更了什麼以及簡短的 commit SHA。對於被告知只需回答而不需變更程式碼的項目，請回覆指定的文字。如果你認為某個項目不應變更，不要在討論串中爭論；將其保留並在報告中說明。
- 使用報告結束，如果每個項目都已處理則使用
done，否則使用blocked。
報告
以完全相同的格式結束你的最終訊息，以便協調者可以解析：
RESULT: done | blocked | needs-split | already-met
TICKET: <local id> / <tracker key or "unpublished">
PR: <url or "none">
BRANCH: <branch or "none">
SKIPPED: <deliberate limits or items not addressed, or "none">
NOTES: <one or two lines: why blocked, what to split, follow-ups, unrelated issues found>