apply

name: apply description: > 當使用者指定 propose 產出的功能資料夾路徑，並要求開始或繼續實作時，必須載入此技能。 從路徑自動推斷根路徑，讀取資料夾下的三份文檔，依 TDD 流程先逐一撰寫測試，再實作未完成任務並更新 checkbox 狀態。 觸發情境包含但不限於：「apply」、「開始實作」、「繼續實作」、「apply frontend/docs/propose/feature-name」、 「apply backend/docs/propose/feature-name」、「apply docs/propose/feature-name」、「按照任務清單實作」。 使用者通常會在新 session 中指定功能路徑來呼叫此技能，不依賴 propose 的對話 context。

Apply

依照 propose 產出的三份文檔，以 TDD 流程逐一撰寫測試、實作任務並更新完成狀態。

前置確認

根路徑與文檔定位

從使用者提供的路徑或指令中自動推斷根路徑 {root}，依序嘗試：

1. 路徑包含 frontend/ 前綴 → {root} = frontend
2. 路徑包含 backend/ 前綴 → {root} = backend
3. 未指定前綴 → 依序嘗試 frontend/docs/propose/<feature-name>/、backend/docs/propose/<feature-name>/、docs/propose/<feature-name>/，找到三份文檔（01-flow.md、02-gherkin.md、03-tasks.md）的路徑即為正確根路徑

三個路徑都找不到文檔，才詢問使用者確認路徑。

執行流程

1. 載入 context

讀取三份文檔：

• 01-flow.md：了解業務邏輯與邊界
• 02-gherkin.md：了解每個任務的完成標準
• 03-tasks.md：取得任務清單，依以下格式判斷狀態：
  • 所有方括號標記皆採大小寫不敏感比對，例如 [bdd]、[BDD]、[Bdd] 視為相同標記
  • - [ ] Tx: → 測試尚未撰寫，實作尚未開始
  • - [BDD] Tx: → 測試已撰寫，等待實作
  • - [x][BDD] Tx: → 測試與實作已完成，測試已通過
  • - [x] Tx: → 舊版標記，視為實作已完成但尚未依 TDD 流程補齊 BDD 狀態
  • - [x][bdd] Tx: → 舊版完成標記，視為已完成；若本次需要編輯該行，統一更新為 [x][BDD]

2. 測試先行階段

依照 03-tasks.md 的任務順序，先為所有一般任務（無 [manual] 標記）逐一撰寫測試。只要仍有一般任務未標記 [BDD]、[x][BDD] 或舊版 [x][bdd]，不得開始實作任何任務。

1. 告知使用者目前執行哪個任務（T1: <描述>）
2. 使用 Skill tool 呼叫 bdd-unit-test，依 02-gherkin.md 與該任務描述撰寫該任務的 BDD 行為測試
3. 02-gherkin.md 為唯讀文件，禁止修改
4. 若發現 02-gherkin.md 中的行為定義有誤（如邏輯矛盾、與實作架構根本衝突），必須立即停止，回報給使用者討論，等待確認後再繼續，禁止自行修改 02-gherkin.md
5. 測試撰寫完成後，將 03-tasks.md 中該任務的 [ ] 更新為 [BDD]
6. 若專案已有可執行的目標測試指令，先執行該測試確認測試檔可被載入；測試因尚未實作而失敗是 TDD 的預期紅燈，但語法錯誤、測試框架設定錯誤或與需求無關的錯誤必須先修正
7. 宣告「Tx 測試完成」，直接繼續下一個任務（不等待使用者確認）

若任務有依賴關係（依賴 Tx），測試階段只需要依任務順序撰寫測試，不要求依賴任務已完成實作。

3. 逐任務實作

所有需要自動處理的一般任務都已標記 [BDD]、[x][BDD] 或舊版 [x][bdd] 後，才進入實作階段。依照 03-tasks.md 的任務順序，每次實作一個任務：

1. 告知使用者目前實作哪個任務（T1: <描述>）
2. 實作該任務，依照 01-flow.md 的邏輯、02-gherkin.md 的驗收條件與已撰寫的 BDD 測試
3. 實作完成後，執行對應測試；若測試失敗，自動分析錯誤並修正實作程式碼（不修改 02-gherkin.md），重複執行直到該任務相關測試通過
4. 測試通過後，將 03-tasks.md 中該任務的 [BDD] 更新為 [x][BDD]
5. 產生該任務的 commit message（格式：<type>: <description>）
6. 宣告「Tx 完成」，直接繼續下一個任務（不等待使用者確認）

若任務有依賴關係（依賴 Tx），實作階段必須先確認依賴任務已完成（[x][BDD] 或舊版 [x][bdd]）再執行。

4. 實作規範

遵循專案 CLAUDE.md 的規範：

• 禁止三元嵌套
• 需要加註解的地方：後端業務邏輯、前端邏輯判斷、hook 邏輯、工具函式邏輯
• 不加註解：純 UI 樣式、簡單賦值

全部完成後

所有一般任務（無 [manual] 標記）皆為 [x][BDD] 或舊版 [x][bdd] 後，執行一次整體驗證：

• 執行本次功能相關的完整測試指令，確認所有已撰寫的 BDD 測試通過
• 若測試失敗，自動分析錯誤並修正實作程式碼或測試中與規格不一致的部分；不得修改 02-gherkin.md
• 驗證通過後，向使用者回覆完成訊息，說明所有一般任務已依 TDD 流程完成測試、實作與驗證

中途繼續

若使用者在任務進行到一半時重新開啟對話：

• 讀取 03-tasks.md，依整體狀態決定行動：
  • 所有一般任務皆為 [x][BDD] 或舊版 [x][bdd]：全部完成，告知使用者即可
  • 存在 [ ] 任務：回到「測試先行階段」，從第一個 [ ] 任務開始補測試；不得先實作後面的 [BDD] 任務
  • 不存在 [ ]，但存在 [BDD] 任務：所有待寫測試已完成，從第一個 [BDD] 任務進入「逐任務實作」
  • 存在舊版 [x] 任務：視為舊流程殘留，先為該任務補齊或驗證 BDD 測試，再依實際狀態更新為 [x][BDD]
• 告知使用者目前進度，例如：「T1、T2 已完成測試標記 [BDD]，T3 尚未撰寫測試，先從 T3 補測試」