iterative-development

iterative-development 技能概覽

什麼是 iterative-development

iterative-development skill 是一種 Claude Code 工作流程：每次模型回應後就執行測試，並透過 Stop hook 自動把失敗結果回饋回去。當你想要比一般 prompt 更緊的 TDD 迴圈時，它特別有用，尤其適合需要在每一輪都先驗證、再結束對話的功能開發。

適合誰安裝

這個 iterative-development skill 適合已經依賴測試、lint、或型別檢查的開發者，並希望 Claude 一直待在修正迴圈裡，直到那些檢查全部通過。它很適合 Workflow Automation 類型的設定；但如果你的專案沒有可靠的測試指令，或你比較習慣每次回答後人工審查，那它就沒那麼實用。

在實務上為什麼重要

它的核心價值不是「更會寫 prompt」，而是縮小程式碼生成與驗證之間的落差。這個 skill 會讓 Claude 直接回應真實失敗，幫助你更早抓出錯誤假設、避免一次到位卻沒驗證的實作，並把迭代聚焦在你的 repo 真正會拒絕的地方。

如何使用 iterative-development 技能

安裝並找到工作流程檔案

先依照 iterative-development install 的 repository 安裝流程安裝，然後先打開 SKILL.md。這個 skill 沒有 helper scripts 或額外的資料夾，所以操作邏輯幾乎都集中在那一個檔案裡。如果你想最快掌握重點，請先讀 SKILL.md，再看其他內容。

先從可測試的任務描述開始

iterative-development usage 的模式在 prompt 明確指出具體成果、相關檔案，以及你希望迴圈執行的驗證指令時效果最好。強而有力的描述會像這樣：在 src/auth/ 加入密碼重設驗證，維持既有 API 形狀，且每一輪都執行 npm test 和 npm run lint。 這比「改善 auth」好，因為 hook 需要一個可確定、可驗證的目標。

先讀 hook 邏輯，再決定是否依賴它

在 iterative-development guide 裡，重點要放在說明 Stop hook 如何結束、stderr 如何回傳給 Claude，以及 TDD 迴圈每一輪實際檢查什麼的段落。這些才是決定工作流程是真的持續迭代，還是只在命令失敗後就停下來的關鍵。如果 repo 裡有 Python 版本，先和你的 shell 設定比對過，再考慮移到其他環境，不要直接照抄。

用在驗證成本低、可重複的情境

最適合的輸入是回饋快速的任務：單元測試、lint 規則、型別檢查，或小型整合測試套件。避免拿它來做含糊的研究任務、沒有可重複指令的一次性除錯，或是無法用可檢查失敗來表達「正確結果」的專案。

iterative-development 技能 FAQ

iterative-development 只適合 TDD 嗎？

不是。它確實很適合 TDD，但真正的必要條件是有一個可重複、能快速失敗，並且能明確告訴 Claude 要修什麼的驗證指令。只要迴圈裡有清楚的通過／失敗訊號，你就可以拿來處理程式碼修改、重構和整理工作。

它和一般 prompt 有什麼不同？

一般 prompt 可能只產生一次程式碼，驗證則留給你自己。iterative-development skill 會加入自動停下來並修正的循環，所以 Claude 會立刻看到測試失敗，並能在 session 結束前修正。對 Workflow Automation 來說，這比單純一句「也請寫測試」更可靠。

這個技能適合新手嗎？

如果你已經會跑測試、也看得懂失敗訊息，那它算友善。若你還在熟悉專案工具鏈，它就沒那麼適合新手，因為這個 skill 預設你能找出可信的檢查指令，並理解失敗原因。

什麼情況下不該用？

當你的專案有不穩定的測試、很慢的端對端檢查，或是會產生很多與程式碼變更無關的雜訊失敗時，不要用它。這些情況下，迴圈可能只會浪費時間，或讓 Claude 一直重複修同一類問題，卻無法收斂到真正解法。

如何改進 iterative-development 技能

給迴圈更明確的約束

品質提升最大的地方，是一開始就把確切的指令、檔案和驗收條件講清楚。不要只說「讓它能用」，而是說明哪些必須通過、哪些不能改，以及哪種失敗應被視為 निर्ण定性結果。這樣 iterative-development skill 才更可能收斂到正確修正，而不是四處偏移。

讓失敗更容易解讀

如果測試輸出很長、很不穩定，或含義模糊，Claude 得到的回饋就會變弱。要改進這個 skill，應該縮短驗證路徑、把失敗的指令獨立出來，並讓錯誤面積保持小而清楚。簡潔的失敗測試，比三個彼此因不同原因而失敗的大檢查更有用。

第一輪之後再迭代 prompt

如果第一版輸出已經接近但還不對，就直接補上精準差距：例如「測試已通過，但 hook 還應該執行 npm run typecheck」，或「在更動實作時保持 public API 穩定」。這比從頭重問更有效，因為這個 skill 最適合每一輪只新增一個精確約束。

注意會讓迴圈失效的錯誤

常見失敗包括：使用永遠不會乾淨結束的指令、要求無法自動驗證的目標，或漏掉 repository 真正的測試入口。若迴圈看起來卡住了，就把任務簡化、把 Claude 指向權威測試指令，並確認 Stop hook 真的有設定成透過 stderr 回傳失敗。