subagent-driven-development

subagent-driven-development 技能概覽

subagent-driven-development 技能能幫你把實作工作拆成彼此獨立的任務，為每個任務指派一個新的 subagent，並在往下做之前先檢查結果。它特別適合以 agent 協作來加速交付、又不想犧牲品質控管的情境。

當你已經有計畫、待辦清單，或是幾個彼此不共用狀態的 issue 時，可以使用 subagent-driven-development skill。它很適合想要有結構地執行 bug 修復、功能切片、repo 整理，或是需要調查但放在一個長上下文裡會更慢、更雜亂的工作。

這個 subagent-driven-development 技能最擅長的事

這個技能在任務可以依檔案、子系統，或決策點切開時最強。它的主要價值不只是平行處理，而是透過每個任務都從乾淨的 subagent 開始，並在繼續前先檢查輸出，來降低上下文污染。

什麼情況下適合使用 subagent-driven-development

當你需要處理 3 個以上彼此獨立的問題，或是 roadmap 已經有清楚步驟、可以依序執行而且中間有 review gate 時，這個 workflow 很值得用。若你想要的是可重複使用的 subagent-driven-development guide，而不是臨場拼湊的 prompt，它也特別合適。

可以期待什麼

你可以期待的是任務切分與審核流程，不是什麼神奇的全自動駕駛。當你已經知道工作邊界時，這個技能能同時提升速度與品質；但如果問題本身很模糊、耦合很高，或每一步都必須共用同一條推理鏈，那它的幫助就比較有限。

如何使用 subagent-driven-development 技能

安裝並掛載這個技能

先在你的 agent 環境中使用 subagent-driven-development install 流程，然後在開始規劃前載入這個技能。若你的平台支援從 repo 安裝 skill，請指向 NeoLabHQ/context-engineering-kit 以及 plugins/sadd/skills/subagent-driven-development 路徑。

把粗略目標整理成可用的 prompt

這個技能在你提供以下內容時效果最好：

• 目標 repo 或工作區
• 你想要的精確結果
• 一份彼此獨立的任務或 issue 清單
• 任何範圍、測試，或要避免修改哪些檔案的限制

例如，不要只寫「修 auth 區塊」，而是改成：「把 login flow、token refresh、error handling 分成獨立任務；每個項目指派一個 subagent；每完成一項就先 review 再繼續。」

先讀這些檔案

先從 SKILL.md 開始，理解執行模式。接著如果附近有其他文件或 repo 慣例，也一併查看。在這個 repo 裡沒有支援資料夾，所以主要的事實來源就是 skill 本體。這也代表，第一次閱讀對於做出 subagent-driven-development usage 的判斷特別重要。

在實際工作流程中使用它

一個好的流程是：先定義任務、把獨立工作分組、每個任務派一個新的 subagent、檢查 code 和輸出，然後決定要繼續、修正，還是停止。對 subagent-driven-development for Agent Orchestration 來說，關鍵是讓每個 subagent 的範圍都夠窄，並且在每個任務或每一批之後就 review，而不是等到最後才一次看完。

subagent-driven-development 技能 FAQ

這比一般 prompt 更好嗎？

當工作有可拆分的部分，而且你想設下品質門檻時，答案是肯定的。一般 prompt 可以應付一次性的變更，但 subagent-driven-development skill 能為多步驟的實作工作提供更有紀律的執行迴圈。

這會取代人工 review 嗎？

不會。它能降低錯誤在任務之間一路被帶下去的機率，但你仍然需要在關鍵決策點做 review。這個技能的目標是讓 review 成本更低，不是讓 review 變成可有可無。

這個技能對初學者友善嗎？

如果你能清楚描述任務與邊界，它對初學者是友善的；但如果你還無法判斷兩個 issue 是彼此獨立，還是高度耦合，那就會比較難用得好。

什麼時候不該用它？

小幅編輯、高度糾纏的重構，或需要同一條調查路徑才能解決的問題，就不建議使用。這些情況下，subagent 協作的額外成本可能會超過它帶來的好處。

如何改進 subagent-driven-development 技能

給 subagent 更清楚的任務邊界

輸入越好，輸出通常也越好。不要只說「改善 codebase」，而要說「把 lint 修正和 test failures 分開，然後逐個檔案群組獨立 review」。邊界清楚，技能才比較能在不重疊的前提下分派工作。

加上驗收條件與停止條件

明確說出什麼才算完成：改了哪些檔案、哪些測試要通過、風險上限，或不能變更 API 的限制。這會讓 subagent-driven-development guide 更有可操作性，也能避免 subagent 做過頭。

注意常見失敗模式

最常見的失敗是任務重疊、範圍模糊，以及子任務之間依賴太多。如果某個任務需要另一個任務的共享狀態，先把它們合併，再派發 subagent。

第一次跑完後再迭代

第一次輸出不要只拿來判斷通過或退回，也要拿來調整任務粒度。如果某個 subagent 回來的內容太大，就把工作再切細；如果切得太碎，就把相關檢查合併成一個 review 迴圈。