工程師
將探索成果綜合為兩個持久化的產物：一份可讓 /implement 執行的規格書，以及針對值得記錄的決策所撰寫的 ADR。
輸入：$ARGUMENTS。
零隱性假設。 每個設計選擇都需由使用者決定，或列為假設。這包括那些您覺得小到不需過問的選擇（函式庫、錯誤格式、命名、預設值、限制）、您從程式碼庫推斷的內容，以及您自己的建議。在整個過程中，維護一份假設登記冊（✅ 使用者已確認 · ❓ 未確認 · ❌ 已拒絕），且絕不將未經確認的選擇以「決策」的形式寫入規格書或 ADR。
流程
- 精煉。 如果此工作階段尚無「精煉簡報」，請先執行
/refine流程（審查 → 驗收標準）。若有阻礙設計的開放性問題，請勿繼續。若已有簡報，請將其 ❓ 假設納入您的登記冊中；在解決這些假設之前，請勿設計任何依賴於它們的內容。 - 建模。 針對任何新增或變更的概念，執行
/domain-modelling流程並更新領域文件。規格書必須使用這些標準術語。 - 探索程式碼庫。 找出變更所觸及的模組、介面、資料儲存及測試。注意需遵循的現有模式。引用真實路徑。程式碼當前的行為是證據，而非意圖：「遵循
src/x.ts中的現有模式」本身就是一個需要與使用者確認的選擇，並需附上來源進行記錄。 - 設計。 針對每個重大決策，提出 2-3 個選項，附帶取捨比較與建議；最終由使用者決定，且您的建議僅在使用者明確選擇後才算數。對於較小的選擇，將其彙整為一份確認清單，而不是自行決定。考慮資料模型與遷移、API/合約變更、錯誤處理、安全性、效能、可觀測性、上線與回退策略，以及向後相容性。
- 記錄 ADR。 若某個決策難以逆轉、影響多個模組，或未來工程師會問「我們為什麼這樣做？」，則值得為其撰寫 ADR。每個 ADR 寫入
docs/adr/NNNN-kebab-title.md（使用下一個可用編號，4 位數），並遵循 adr-template.md。若某個 ADR 取代了另一個，請更新舊 ADR 的狀態。僅在使用者確認決策後，才能將 ADR 標記為Accepted；否則維持Proposed。 - 撰寫規格書 至
docs/specs/<kebab-title>.md，使用 spec-template.md。將工作拆解為小型、有序、可獨立測試的任務——每個任務都附帶證明其完成的測試。從登記冊中填寫規格書的假設章節；每個設計陳述都必須追溯到使用者的決策，或作為 ❓ 出現在該章節中。 - 與使用者一同審查。 總結規格書與 ADR，顯示開放的 ❓ 項目，請求核准並進行調整。當有任何 ❓ 影響到任務、驗收標準或 ADR 時，請勿將規格書設為
Approved。
規則
- 如果專案已有現成的規格書/ADR 資料夾或範本，請尊重並使用這些既有慣例。
- 規格書描述的是「要做什麼」以及「如何驗證」，並提供足夠的「如何做」來消除歧義——而不是逐行實作的細節。
- 每個驗收標準必須對應到至少一個任務與一個測試。
- 讓文件保持與變更規模相符的簡潔度。
下一步
建議執行 /handoff（以便在全新工作階段中開始實作）或直接執行 /implement docs/specs/<file>.md。