tdd-workflow

tdd-workflow 技能概覽

tdd-workflow 的用途

tdd-workflow 是一個以測試優先的執行技能，適用於功能開發、修 bug 與重構。它的設計目標，是幫助你把一個粗略的實作想法，推進成經過單元測試、整合測試與 E2E 測試驗證的程式碼，而不是事後補救式地修修補補。

適合安裝哪些人

如果你希望 app 程式碼、API、UI 變更，或大量自動化工作有更嚴格的開發迴圈，就適合安裝 tdd-workflow 技能。當你需要可預測的覆蓋率、明確的邊界情況處理，以及可重複的 Test Automation 操作順序時，它特別有用。

為什麼它特別值得安裝

tdd-workflow 的核心價值在於紀律：先寫測試，再寫程式碼，覆蓋率目標清楚，而且每個階段都要求有證據。這讓它比一般「寫測試」提示更有決策價值，因為它會推著代理先規劃、驗證、做 checkpoint，而不是直接跳進實作。

如何使用 tdd-workflow 技能

安裝並啟用

可以使用這個 repo 的 tdd-workflow install 流程，或在你的 Claude Code skills path 中手動加入，如果你的環境是以手動方式管理 skills。重點是，代理在開始寫程式之前就要先看到這個 skill，而不是等到第一版草稿都已經出來之後才套用。

讓技能接到正確的任務形狀

tdd-workflow usage 的模式，在你的需求有清楚說明變更內容、風險與預期驗證方式時最有效。弱的輸入會像「修登入」。較強的輸入則會像「新增密碼重設驗證、覆蓋 API 與 UI 的錯誤狀態，並保持目前的 auth contract 不變。」第二種寫法能提供足夠結構，讓技能先寫測試，並選擇正確的單元、整合與 E2E 覆蓋組合。

先讀這些檔案

先從 SKILL.md 開始，再檢查 repo 裡的 README.md、AGENTS.md、metadata.json，以及任何存在的 rules/、resources/、references/ 或 scripts/ 資料夾。就這個 repo 而言，SKILL.md 是唯一可見的來源檔，所以要把它視為 canonical 的工作流程規格，並依照目標專案的測試堆疊與限制來調整。

依照流程順序執行

先用這個 skill 定義會失敗的測試，再實作最小的程式碼變更讓測試通過，接著跑下一層驗證。如果你的 repository 支援 Git checkpoints，建議在每個 TDD 階段後都保留一個 commit，這樣證據軌跡會更清楚，也更容易回復。當工作同時跨越後端邏輯、API 邊界與瀏覽器行為時，這點尤其重要。

tdd-workflow 技能 FAQ

tdd-workflow 只適合大改動嗎？

不是。tdd-workflow skill 對小型 bug 修正也很有幫助，尤其是 bug 很隱晦，或很可能再次回歸時。相較之下，對於單純的文案修改，或不需要分階段驗證的一行設定變更，它的價值就比較有限。

我一定要先有成熟的測試套件嗎？

不一定，但你至少要有足夠的測試工具，讓這套流程真的能跑起來。如果專案沒有實用的 unit、integration 或 E2E 設定，tdd-workflow guide 還是能在流程面提供幫助，但覆蓋率目標可能需要依照 repo 實際的測試邊界調整。

這和一般提示有什麼不同？

一般提示可能會同時要求程式碼和測試。tdd-workflow 改變的是順序與決策規則：先測試、覆蓋範圍要明確、驗證則依測試類型分階段進行。這通常能在做 Test Automation 或處理跨多層 stack 的工作時，減少猜測成本。

這對初學者友善嗎？

可以，只要你看得懂測試失敗訊息，並能跟著一步一步的迴圈走。初學者會受益於這種結構，但任務範圍要收窄，並提供清楚的驗收標準；否則這套流程可能會讓人覺得很嚴格，而不是有幫助。

如何改進 tdd-workflow 技能

提供更精準的驗收條件

最好的 tdd-workflow 輸入，會清楚說明什麼一定要能運作、什麼不能改變，以及要怎麼檢查成功。請包含輸入、輸出、失敗情境，以及任何相容性限制。例如：「拒絕空白的 email、保留既有 response shape，並同時覆蓋 browser 路徑與 API 錯誤處理。」

指定正確的測試組合

如果你指出風險落在哪裡，這個 skill 的表現會更好。變更若碰到 business logic，就先要求 unit tests；若跨越 service 邊界，就要有 integration coverage；若使用者旅程很重要，就加入 E2E 檢查。這樣可以避免流程過度依賴單一測試類型，而錯過真正的失敗模式。

留意常見失敗模式

最常見的問題，是在測試還不穩定時就過度實作。另一個問題，是把 80%+ coverage 當成打勾清單，而不是提醒自己要補 edge cases、邊界與錯誤路徑。如果第一次產出範圍太大，就縮小 scope，然後用一次只處理一個情境的方式重新跑 tdd-workflow usage 迴圈。

用證據持續迭代

拿到第一版結果後，先檢查是哪個測試失敗、證明了哪些行為、還有哪些地方尚未被測到。接著請求下一個最小增量，而不是整份重寫。對 tdd-workflow for Test Automation 來說，這通常代表先收緊 selectors、補上明確 assertions 與 negative-case coverage，再往更多使用者流程擴充。