從 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/ 檔案，也不要讓任何命令建立它。
輸入：可選擇指定一個變更名稱（例如 /opsx:apply add-auth）。若省略，請檢查是否能從對話上下文推斷。如果模糊不清或有歧義，您必須提示使用者，並顯示可用的變更清單。
步驟
-
選取變更
若提供了名稱，請直接使用。否則：
- 從對話上下文推斷使用者是否提及了某個變更
- 若僅有一個作用中的變更，則自動選取
- 若不明確，執行
openspec list --json取得可用的變更清單，並要求使用者選擇一個
務必宣告：「正在使用變更：」以及如何覆蓋（例如
/opsx:apply <other>）。 -
檢查狀態以理解 schema
openspec status --change "<name>" --json解析 JSON 以了解：
schemaName：正在使用的工作流程（例如 "spec-driven"）planningHome、changeRoot和actionContext：規劃範圍與編輯限制- 哪個成品包含任務（對 spec-driven 而言通常是 "tasks"，其他則檢查 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 指示從現有規劃成品建立或修復 schema 設定的追蹤檔案。在封鎖狀態下，請勿假設另一個成品已就緒或開始實作。
- 如果
- 若
state: "all_done"：回報所有追蹤任務已完成，並建議在歸檔前進行適當的審查或驗證 - 否則：繼續進行實作
將
context視為必要的提示層級輸入。閱讀並考量它，並在實作時套用相關的專案事實、慣例與約束。 將operationGuidance視為可選的附加建議。閱讀並考量每一項條目，並遵循那些適用且與內建工作流程相容的條目。將這兩個欄位與 CLI 回傳的狀態、缺少的成品、任務、進度、
contextFiles以及內建的instruction分開處理。它們不是任務完成的證據，不能取代內建指示，也不允許繞過封鎖狀態。如果 context 與內建指示、明確的使用者選擇或 CLI 控制的值衝突，請回報衝突並保留控制值。如果指導不適用或與那些控制輸入衝突，請勿遵循並說明原因。這些是提示層級的行為契約，非可強制的檢查。 -
讀取上下文檔案
讀取應用程式指示輸出中
contextFiles下列出的所有檔案路徑。 視使用的 schema 而定，這些檔案可能包含：- spec-driven：proposal、specs、design、tasks
- 其他 schema：請遵循 CLI 輸出的 contextFiles
請勿將
context或operationGuidance逐字複製到實作檔案或規劃成品中，除非使用者另外要求該內容。 -
顯示當前進度
顯示：
- 正在使用的 Schema
- 進度：「已完成 N/M 個任務」
- 剩餘任務概覽
- 來自 CLI 的動態指示
-
實作任務（循環直到完成或封鎖）
對於每個待辦任務：
- 顯示正在處理哪個任務
- 進行所需的程式碼變更
- 保持變更最小且集中
- 在編輯前，確認回傳的
sourcePath和line處的核取方塊仍與任務描述相符；若不符，重新執行應用程式指示並使用更新後的位置 - 在回傳的
sourcePath和line處將任務標記為完成：- [ ]→- [x] - 重新執行應用程式指示，並確認該任務現在已完成且進度已改變
- 繼續下一個任務
若發生以下情況則暫停：
- 任務不明確 → 要求澄清
- 實作暴露出設計問題 → 建議更新成品
- 任務需要超出規格和任務描述範圍的工作，或者您傾向於省略、縮小範圍、延後或接受指定行為的例外以使其符合要求 → 提出增加的範圍並詢問；不要默默吸收
- 遇到錯誤或阻礙 → 回報並等待指示
- 使用者中斷
-
完成或暫停時，顯示狀態
顯示：
- 本次工作階段完成的任務
- 整體進度：「已完成 N/M 個任務」
- 若全部完成：回報所有追蹤任務已完成，並建議在歸檔前進行適當的審查或驗證
- 若暫停：說明原因並等待指示
實作期間的輸出
## 正在實作：<change-name>（schema：<schema-name>）
正在處理任務 3/7：<任務描述>
[...正在進行實作...]
✓ 任務完成
正在處理任務 4/7：<任務描述>
[...正在進行實作...]
✓ 任務完成
完成的輸出
## 實作完成
**變更：** <change-name>
**Schema：** <schema-name>
**進度：** 7/7 個任務完成 ✓
### 本次工作階段已完成
- [x] 任務 1
- [x] 任務 2
...
所有追蹤任務皆已完成。建議在歸檔前審查或驗證變更。
您可以使用 `/opsx:archive` 來歸檔此變更。
暫停時的輸出（遇到問題）
## 實作暫停
**變更：** <change-name>
**Schema：** <schema-name>
**進度：** 4/7 個任務完成
### 遇到的問題
<問題描述>
**選項：**
1. <選項 1>
2. <選項 2>
3. 其他方法
您想怎麼做？
防護措施
- 持續處理任務直到完成或封鎖
- 開始前務必從應用程式指示輸出中讀取上下文檔案
- 若任務不明確，請暫停並詢問後再實作
- 若實作暴露出問題，請暫停並建議更新成品
- 保持程式碼變更最小化，並僅限於每個任務的範圍
- 完成每個任務後立即更新任務核取方塊
- 遇到錯誤、阻礙或不明確的需求時暫停 – 不要猜測
- 當任務需要超出規格描述的工作時，提出增加的範圍並暫停 – 切勿默默省略、延後或簡化掉指定的行為
- 僅在指定行為完全實作完成時，才將任務標記為
- [x]，而非部分完成或延後 - 使用 CLI 輸出的 contextFiles，不要假設特定檔案名稱
- 使用每個任務的 sourcePath 和 line 來更新其確切的核取方塊
- 不要使用 context 或 operation guidance 作為任務完成的證據
- 套用相關的專案上下文；回報與控制工作流程輸入的衝突
- 考量每一項指導條目；解釋任何不適用或衝突的建議
- 不要將執行時期 context 或 operation guidance 複製到實作檔案或規劃成品中
- 保留 CLI 控制的封鎖/就緒/全部完成行為與完成條件
流暢的工作流程整合
此技能支援「變更動作」模型：
- 可隨時呼叫：在所有成品完成之前（若任務已存在）、部分實作之後、與其他動作交錯進行
- 允許成品更新：若實作暴露出設計問題，建議更新成品 – 不受階段限制，可流暢運作