執行 OpenSpec 變更中的任務。
商店選取： 如果使用者指定了商店（商店是在本機註冊的獨立 OpenSpec 儲存庫），或者工作存在於某個商店內，請執行 openspec store list --json 來探索已註冊的商店 ID，然後在讀取或寫入規格與變更的指令（如 new change、status、instructions、list、show、validate、archive、doctor、context、schemas、view）中傳遞 --store <id>。一旦選定，請將 --store <id> 視為黏性參數，用於工作流程的其餘部分。以下每個未限定範圍的指令範例都是簡寫：在執行之前，請附加該旗標。例如，請執行 openspec status --change "<name>" --json --store "<id>"，而不是下方所示的未限定形式。其他指令不接受此旗標。指令輸出的提示已包含此旗標；在後續操作中請保持該旗標。如果沒有商店，指令則會作用於最近的本地 openspec/ 根目錄。
專案檢查： 這些步驟假設專案已使用 OpenSpec。在執行任何會寫入內容的第一步（例如 new change、archive、sync specs 或撰寫工件檔案）之前，請確認專案具有根目錄：執行 openspec list --json（若已選取商店，則加上 --store <id>，因為此時商店就是根目錄），並檢查 root。如果 root 是一個物件，表示專案已設定。如果 "root": null，表示專案尚未設定 – 這裡沒有 openspec/ 目錄，而像 openspec new change 這樣的寫入操作會產生副作用並建立該目錄。此指令也會以非零狀態碼退出，但這代表的是上述情況，而非 CLI 故障，因此請讀取 JSON，不要重試或嘗試繞過。
有一種 "root": null 的情況與專案設定無關：當 status 錯誤訊息以 Declared in 或 Invalid store declaration in 開頭，並指出此專案的 openspec/config.yaml（或 config.yml）時，表示該專案是透過其宣告的商店來使用 OpenSpec，但此機器無法解析該商店（商店未註冊，或 store: 一行格式錯誤）。請勿將其視為未初始化並略過以下分支：請在寫入前停止，並向使用者顯示該錯誤的 message 和 fix。
否則，如果沒有根目錄，後續步驟取決於此工作流程是如何啟動的：
- 自動選取：您自行選擇了此工作流程，而非使用者指定了 OpenSpec、此技能名稱或執行了其斜線指令。請停止使用 OpenSpec，並像沒有安裝 OpenSpec 一樣正常回覆請求。不要要求他們設定任何東西，也不要提到 OpenSpec 的設定。
- 明確的 OpenSpec 請求：使用者指定了 OpenSpec、此技能名稱或執行了其斜線指令。請在寫入前停止，並詢問如何繼續：設定此專案（
openspec init）、指定他們已有的商店（--store <id>），或是忽略 OpenSpec 來處理此請求。等待他們的回覆。
在這兩種分支中，絕對不要讓根目錄作為副作用被建立：不要執行 openspec init，除非使用者要求；不要手動建立 openspec/ 檔案；也不要讓任何指令建立它。
輸入：可選擇性地指定變更名稱（例如 /openspec-apply-change add-auth）。如果省略，請檢查是否能從對話脈絡推斷。如果模糊或不明確，您必須提示可用的變更。
步驟
-
選取變更
如果提供了名稱，請使用它。否則：
- 如果使用者提到某個變更，請從對話脈絡推斷
- 如果只有一個作用中的變更，則自動選取
- 如果不明確，請執行
openspec list --json取得可用的變更，並要求使用者選取一個
務必宣佈：「使用變更：<名稱>」以及如何覆寫（例如
/openspec-apply-change <其他>）。 -
檢查狀態以了解結構
openspec status --change "<name>" --json解析 JSON 以了解：
schemaName：正在使用的工作流程（例如 "spec-driven"）planningHome、changeRoot和actionContext：規劃範圍和編輯限制- 哪個工件包含任務（對於 spec-driven 通常是 "tasks"，其他 schema 請檢查 status）
-
取得套用指令
openspec instructions apply --change "<name>" --json這會回傳：
contextFiles：工件 ID -> 具體檔案路徑陣列（依 schema 而異 – 可能是 proposal/specs/design/tasks 或 spec/tests/implementation/docs）- 進度（總數、完成數、剩餘數）
- 任務清單，包含狀態、原始檔路徑和行號
- 基於當前狀態的動態指令
- 可選的
context：來自所選根目錄的當前必要專案指令輸入 - 可選的
operationGuidance：當前針對套用操作的建議指導 missingArtifacts（若存在）：必要但沒有輸出的工件 ID
處理狀態：
- 如果
state: "blocked"：顯示訊息並暫停實作。- 如果
missingArtifacts非空：建議完成缺失的工件。執行openspec status --change "<name>" --json，選取下一個狀態為ready的工件（非skipped或blocked），並使用openspec instructions "<artifact-id>" --change "<name>" --json取得其規則和範本。在這兩個指令中保持使用選定的--store <id>。 - 否則，請遵循 CLI 指令，從現有的規劃工件建立或修復結構設定的追蹤檔案。在阻塞狀態下，不要假設有其他工件已準備就緒，也不要開始實作。
- 如果
- 如果
state: "all_done"：回報所有追蹤的任務已完成，並建議在歸檔前進行適當的審查或驗證 - 否則：繼續進行實作
將
context視為必要的提示層級輸入。閱讀並考慮它，並在實作時套用相關的專案事實、慣例和限制。 將operationGuidance視為可選的附加建議。閱讀並考慮每個條目，並遵循那些適用且與內建工作流程相容的條目。將這兩個欄位與 CLI 回傳的狀態、缺失的工件、任務、進度、
contextFiles以及內建的instruction區分開來。它們不是任務完成的證據，不取代內建指令，也不允許繞過阻塞狀態。如果 context 與內建指令、明確的使用者選擇或 CLI 控制的值衝突，請回報衝突並保留控制值。如果 guidance 不適用或與上述控制輸入衝突，請不要遵循它，並解釋原因。這些是提示層級的行為合約，而非可強制執行的檢查。 -
讀取脈絡檔案
讀取套用指令輸出中列在
contextFiles下的每個檔案路徑。 這些檔案取決於所使用的結構：- spec-driven：proposal、specs、design、tasks
- 其他結構：遵循 CLI 輸出中的 contextFiles
除非使用者另外要求，否則不要將
context或operationGuidance的內容逐字複製到實作檔案或規劃工件中。 -
顯示當前進度
顯示：
- 正在使用的結構
- 進度：「N/M 個任務完成」
- 剩餘任務概覽
- 來自 CLI 的動態指令
-
實作任務（循環直到完成或阻塞）
針對每個待處理的任務：
- 顯示正在處理哪個任務
- 進行所需的程式碼變更
- 保持變更最小且集中
- 在編輯前，確認回傳的
sourcePath和line處的核取方塊仍然與任務描述相符；如果不符合，請重新執行套用指令並使用重新整理後的位置 - 在回傳的
sourcePath和line處將任務標記為完成：- [ ]→- [x] - 重新執行套用指令，並確認該任務現在已完成且進度已變更
- 繼續到下一個任務
以下情況暫停：
- 任務不明確 → 要求釐清
- 實作揭示設計問題 → 建議更新工件
- 任務需要超出規格和任務描述範圍的工作，或者您傾向於悄悄地縮小、延後、接受指定行為的例外情況以使其符合 → 提出增加的範圍並詢問；不要默默吸收
- 遇到錯誤或阻塞 → 回報並等待指示
- 使用者中斷
-
完成或暫停時，顯示狀態
顯示：
- 本次階段完成的任務
- 整體進度：「N/M 個任務完成」
- 如果全部完成：回報追蹤的任務已完成，並建議在歸檔前進行適當的審查或驗證
- 如果暫停：說明原因並等待指示
實作期間的輸出
## Implementing: <變更名稱> (schema: <結構名稱>)
正在處理任務 3/7：<任務描述>
[...實作進行中...]
✓ 任務完成
正在處理任務 4/7：<任務描述>
[...實作進行中...]
✓ 任務完成
完成時的輸出
## Implementation Complete
**變更：** <變更名稱>
**結構：** <結構名稱>
**進度：** 7/7 個任務完成 ✓
### 本次階段完成
- [x] 任務 1
- [x] 任務 2
...
所有追蹤的任務已完成。請在歸檔前進行適當的審查或驗證此變更。
您可以使用 `/openspec-archive-change` 來歸檔此變更。
暫停時的輸出（遇到問題）
## Implementation Paused
**變更：** <變更名稱>
**結構：** <結構名稱>
**進度：** 4/7 個任務完成
### 遇到的問題
<問題描述>
**選項：**
1. <選項 1>
2. <選項 2>
3. 其他方法
您想要怎麼做？
防護措施
- 持續處理任務直到完成或阻塞
- 在開始前務必先讀取脈絡檔案（來自套用指令的輸出）
- 如果任務不明確，先暫停並詢問，再進行實作
- 如果實作揭示問題，暫停並建議更新工件
- 保持程式碼變更最小且範圍限定在每個任務內
- 在完成每個任務後立即更新任務核取方塊
- 在遇到錯誤、阻塞或需求不明確時暫停 – 不要猜測
- 當任務需要超出規格描述的工作時，提出增加的範圍並暫停 – 絕不悄悄地縮小、延後或簡化指定的行為
- 僅在指定行為完全實作時才將任務標記為
- [x]，而非部分完成或延後時 - 使用 CLI 輸出中的 contextFiles，不要假設特定的檔案名稱
- 使用每個任務的 sourcePath 和 line 來更新其精確的核取方塊
- 不要使用 context 或 operation guidance 作為任務完成的證明
- 套用相關的專案脈絡；回報與控制性工作流程輸入的衝突
- 考慮每個 guidance 條目；解釋任何不適用或衝突的建議
- 不要將執行階段脈絡或 operation guidance 複製到實作檔案或規劃工件中
- 保留 CLI 控制的 blocked/ready/all-done 行為和完成標準
流暢的工作流程整合
此技能支援「對變更執行動作」模型：
- 可隨時呼叫：在所有工件完成之前（如果有任務存在）、部分實作之後，或與其他動作交錯進行
- 允許工件更新：如果實作揭示設計問題，建議更新工件 – 不是階段鎖定的，可以流暢地工作