spec-driven-development
作者 addyosmanispec-driven-development 是一種先寫規格、後寫程式的工作流程技能，接著依序推進規劃、任務拆解與實作，並在每個階段加入人工審核。
這個技能獲得 74/100，屬於表現穩健、但尚未達到頂級水準的目錄收錄候選。對目錄使用者來說，這代表它對需要 spec-first 工作流程的 agent 確實有實用價值，也有足夠的流程結構可減少摸索成本；但目前仍缺少配套檔案與封裝完善的操作指引，導入時不算完全零摩擦。
- 觸發情境說明清楚：適合用於啟動新專案、新功能或需求仍有模糊空間的變更，也明確指出不適用於瑣碎修補。
- 操作流程扎實：採用四個有關卡的階段（Specify → Plan → Tasks → Implement），且每一步都納入人工審核。
- 實務細節完整：SKILL.md 內容相當充實，含多個標題、限制說明與程式碼範例，讓 agent 更容易依流程執行。
- 沒有支援檔案或安裝指令：是否能順利採用，幾乎完全仰賴 SKILL.md 內的說明。
- 以單一檔案交付：缺少可強化流程的腳本、參考資料或其他資源，較難涵蓋例外情況與邊界案例。
spec-driven-development skill 概覽
spec-driven-development 是一種先寫清楚規格、再依據規格推進規劃、任務拆解與實作的工作流程型 skill。當你要開始新功能、調整架構，或面對需求還很模糊的情境時，這個 spec-driven-development skill 特別合適，因為它能幫你在最終交付前減少憑空假設與方向偏差。
這個 skill 適合拿來做什麼
當主要風險是「做錯東西」，而不只是「把東西做得不夠好」時，就很適合使用這份 spec-driven-development 指南。它能把一個粗略想法整理成團隊共用的單一事實來源，在投入實作之前先把範圍、行為、限制條件與驗收標準定清楚。
最適合導入的情境
這個 skill 很適合需要與人工審查者更緊密對齊的團隊或個人開發者，尤其是工作會跨多個檔案、依賴產品決策，或規模大到不能只靠「先寫再說」的情況。它也很適合用於 Skill Authoring 的 spec-driven-development，特別是當你希望 skill 本身能產出更有紀律、可審查的結果時。
它和一般做法有什麼不同
它的核心價值在於有明確關卡的流程：先定規格、再做規劃、再拆任務、最後才實作，而且每一階段都要經過人工審查。這讓它比一般 prompt 更有約束力，因為它能更早暴露隱含假設，迫使關鍵決策提前發生，而不是等到改動成本變高後才返工。
如何使用 spec-driven-development skill
安裝並先載入上下文
若要安裝 spec-driven-development，先把這個 skill 加到你的 agent skills 設定中，然後第一步就先打開 skill 檔案：
npx skills add addyosmani/agent-skills --skill spec-driven-development
接著在做任何事之前，先讀 SKILL.md。這個 repository 沒有提供像 rules/、references/ 或 scripts/ 這類輔助資料夾，所以幾乎所有 skill 的上下文都集中在主 skill 檔案裡。
給這個 skill 一個具體的起點
spec-driven-development 的使用模式，在你提供明確目標、限制條件與已知未知時效果最好。弱的輸入會像是「做一個 dashboard」。強的輸入則會像這樣：
「Create a spec for a dashboard that shows subscription health, supports role-based access, and must work with our existing REST API. Ask clarifying questions before drafting the spec. Do not propose implementation details yet.」
這樣的輸入能讓 skill 有足夠上下文去挖出假設，避免太早跳進設計或實作。
遵循有關卡的 spec-driven-development 流程
這個 skill 的設計就是每個階段都先停下來，等確認後再往下走。實務上代表的是：
- 先明確定義問題與假設。
- 規格核准後，再規劃做法。
- 將規劃拆成任務。
- 任務審查後，才進入實作。
如果你跳過這些審查關卡，就等於放棄了這個 skill 最重要的價值：減少因未驗證假設而造成的返工。
先讀內容，再依流程使用
先從 SKILL.md 開始，再把其中的 overview、when to use 與 gated workflow 章節當成你的操作準則。如果你要把它改造成自己的 agent 流程，務必要保留審查檢查點，以及「持續追問直到具體為止」這種行為，因為這兩部分最有機會直接提升輸出品質。
spec-driven-development skill 常見問題
spec-driven-development 比一般 prompt 更好嗎？
通常是，尤其在任務本身模糊、牽涉面廣，或做錯後重工成本很高時。一般 prompt 可以很快產出程式碼，但若你需要先對「到底要做什麼」建立共識，再讓任何人開始寫 code，那 spec-driven-development 會更合適。
什麼情況不該用？
如果只是很小的修改、明確的 bug fix，或是產品面幾乎沒有歧義的獨立變更，就不建議用 spec-driven-development skill。這些情況下，完整跑一次 spec 流程的額外成本，可能比實際工作本身還花時間。
新手也適合嗎？
適合，只要你願意回答釐清問題並審閱草稿。比起自己從零發明流程，這個 skill 其實更容易上手，因為它會要求 agent 暫停、揭露假設，並按順序走完每個階段。
適合用在 Skill Authoring 流程嗎？
適合，尤其是用於 Skill Authoring 的 spec-driven-development，當你想要一套可重複執行的流程，來撰寫新 skill 或升級既有 skill 時。當 authoring 任務需要清楚範圍、審查關卡，以及一份能在實作前先驗證的 spec，它的價值會特別明顯。
如何改進 spec-driven-development skill 的使用效果
一開始就提供更銳利的輸入
最好的結果通常來自你一開始就說清楚目標使用者、期待成果、限制條件，以及哪些地方仍不確定。例如：「Migrate the checkout flow without changing the public API, preserve existing analytics events, and identify any dependency risks before planning.」
強制 skill 先點出假設
常見失敗模式之一，是 spec 看起來完整，實際上卻把關鍵決策藏了起來。你可以要求 model 在起草 spec 前先列出假設，接著由人工工程師先審查這些假設，再進入規劃階段。這通常就是 spec-driven-development 最能省時間的地方。
先迭代 spec，不要急著改 code
如果第一版方向不對，應先修正範圍、驗收標準或限制條件，再要求進入實作。這套流程只有在每次修訂都讓「規格契約」更精準時效果最好，因為後續每個階段都建立在 spec 的精確度之上。
在審查成本高的情境下使用它
當錯誤假設的代價很高時，這個 skill 的價值最高，例如跨多檔案變更、架構調整，或會影響多方利害關係人的功能。如果你的第一版 spec 仍然很模糊，那就應該把它留在 spec 階段多打磨一輪，而不是太早硬推進到任務拆解或寫 code。