Ting

當使用者提供 AC.md（Acceptance Criteria 驗收準則文件），並要求產出測試骨架時，必須載入此技能。 從 AC 文件的每一條 Given/When/Then 直接對應產出測試案例，測試名稱帶 AC 編號（AC001_Given..._When..._Should...）， 作為實作前的行為邊界確認，所有測試預設失敗（紅燈），等實作完成後補上真實斷言。 支援 TypeScript、C#、Java、Python，依照使用者指定語言或詢問後產出對應語言的測試骨架。 觸發情境包含但不限於：「依照 AC 產出測試」、「ac-to-test」、「根據 AC.md 寫測試」。 即使使用者只說「先把 AC 轉成測試」，只要有提供 AC.md 路徑或貼上 AC 內容，也應載入此技能。 注意：此技能用於實作前（無實作檔）；若實作已完成需補測試，請使用 bdd-unit-test 技能。

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

指定一或多個檔案並要求撰寫單元測試時，必須載入此技能。 根據 BDD（行為驅動開發）原則，分析指定檔案的公開方法與邏輯分支，產出涵蓋 Happy Path、Edge Cases、Error Cases 的測試。 觸發情境包含但不限於：「幫這個檔案寫單測」、「write unit test」、「add unit test」。 即使只說「寫測試」或「補測試」，只要有指定目標檔案或貼上程式碼片段，也應載入此技能。

當使用者提供已有的業務流程描述、需求、會議紀錄或需求規格文檔，需要重寫成精確結構化格式，讓每個步驟、if/else 判斷分支、遍歷邏輯都清晰可見時，載入此技能。 觸發信號：描述散亂看不出判斷點、分支條件混在句子裡、if/else 不明顯、遍歷邏輯難追蹤、需要讓步驟和條件明確分離。 典型觸發詞：「流程說明很亂幫我整理」、「把這段描述結構化」、「clarify flow」、「整理需求規格文檔」。 排除：畫 Mermaid 圖、解釋程式碼邏輯、整理 API 文件、翻譯文檔、撰寫全新文件、壓縮精簡文件、或轉換格式。

仿照 TDD 作法，在實作前先對照需求文檔產出 Acceptance Criteria（AC）行為規格文件， 作為 AI 實作迭代的「完成標準」——實作持續迭代直到所有行為測試通過為止。 產出包含需求背景、In/Out Scope、Gherkin 格式驗收條件（AC-001, AC-002...）、測試策略的標準 AC.md， 後續由 ac-to-test 將 AC 轉為測試骨架，再交給 AI 實作。 手動觸發：輸入「export-ac」或「產出 AC」並提供需求文檔路徑。

當使用者提供 Gherkin 文檔、業務邏輯說明或需求規格，並要求產出可被測試框架執行的 Feature File 時，必須載入此技能。 支援 .NET (Reqnroll)、Java (Cucumber-JVM)、JavaScript/TypeScript (Cucumber.js)、Python (Behave) 等框架， 產出符合框架規範的 .feature 檔案，包含 Scenario、Scenario Outline、Examples 等結構。 觸發情境包含但不限於：「幫我產出 feature file」、「把這個轉成 .feature」、「export feature file」、 「根據業務邏輯寫 feature」、「建立測試案例檔」。 即使使用者只說「輸出 feature」或「新增 .feature 檔」，只要有提供業務邏輯或 Gherkin 內容，也應載入此技能。

當使用者提供程式碼、業務邏輯說明或需求文檔，並要求將行為或需求轉換為 Gherkin（Given / When / Then）格式時，必須載入此技能。 目的是產出人類可讀的規格文件，用於與 PM、QA、客戶等非技術人員對齊需求、確認驗收條件，而非直接執行的測試框架檔案。 觸發情境包含但不限於：「幫我轉成 Gherkin」、「把這個邏輯寫成 Given When Then」、「export gherkin」、「把需求整理成 Gherkin 格式」、「幫我對齊需求規格」。 即使使用者只說「幫我寫 Given When Then」或「用 BDD 格式描述這個功能」，只要有提供程式碼或業務邏輯，也應載入此技能。 注意：若使用者要求產出「可被測試框架執行的 .feature 檔案」，應使用 export-feature-file 技能而非此技能。

當使用者提供規格需求文檔，並要求規劃實作方案時，必須載入此技能。 處理規格文檔內的所有待辦項目：新功能需求走完整流程（clarify-flow → Gherkin → 任務清單）， ## bug fix list 依標記分流（[quick-fix] 直接實作、[propose] 走完整流程、無標記自動判斷）， 已完成功能（## 已完成）與已有 > propose: 標記的項目自動跳過不重複提案。 觸發情境包含但不限於：「幫我規劃這個功能」、「propose」、「把需求整理成實作計畫」、 「依照規格文檔產出 propose」、「fix bug」。 即使使用者只說「開始 propose」、提供規格文檔路徑、或規格文檔含有 bug fix list，也應載入此技能。

掃描專案 docs/propose/（或 frontend/docs/propose/、backend/docs/propose/）下所有功能資料夾， 判斷 03-tasks.md 是否全部任務已完成（[x][cr]）， 並將已完成的功能同步更新至使用者指定的規格需求文檔最上方的 ## 已完成 區塊。 觸發情境包含但不限於：「propose-sync」、「同步完成狀態」、「更新規格文檔已完成功能」、 「哪些功能已經實作完成」、「幫我把完成的 propose 同步回規格文檔」。

當使用者需要撰寫、設計、重構任何 React 相關實作時，必須參考此技能。 觸發時機包含但不限於：建立或修改 React 組件（component）、自訂 Hook（custom hook）、服務層（service）、Context、 討論資料夾結構與模組分層、重構現有 React 程式碼、設計 hooks 間的職責與解耦、處理 useEffect 與 setState 的使用方式， 即使使用者只說「幫我寫一個組件」、「用 hook 管理狀態」、「怎麼設計這個功能的架構」，也應載入此技能作為設計依據。