官方 GitHub 與文件說明
Spec Kit 的所有核心資源均集中於官方 GitHub 倉庫。建議先從 README 入門，再依需求深入各子文件。
- Spec Kit 官方倉庫（github/spec-kit） — 包含安裝腳本、模板與完整使用說明
- GitHub 官方部落格：SDD 入門 — 由 GitHub 團隊撰寫的方法論介紹
- Microsoft 開發者文章：Spec-Driven Development — 企業視角的 SDD 實踐說明
- AGENTS.md — 說明各主流 AI 代理（Claude、Copilot、Cursor 等）的整合方式與目錄規範
- 升級指南（upgrade.md） — CLI 版本升級與專案模板遷移的逐步說明
建議閱讀順序：官方 README → AGENTS.md（依你使用的代理選讀對應章節）→ 升級指南（遇到版本衝突時查閱）→ 社群案例（吸收實戰經驗）。
SDD 方法論延伸閱讀（BDD / ATDD）
Spec-Driven Development（SDD）並非憑空出現，其概念根植於行為驅動開發（BDD）與驗收測試驅動開發（ATDD）。理解這些前輩方法論，有助於在團隊中推廣 Spec Kit。
BDD 強調以「行為描述」取代「測試案例」，讓非技術利害關係人也能讀懂需求；ATDD 則進一步將驗收條件具體化為可執行測試。SDD 在 AI 代理的輔助下，把這兩者的精神延伸到規格文件本身。
- BDD（Behaviour-Driven Development）：由 Dan North 提出，以 Given / When / Then 語法描述系統行為，代表工具包含 Cucumber、SpecFlow。
- ATDD（Acceptance Test-Driven Development）：在迭代開始前即與客戶共同定義驗收條件，驅動開發方向。Robot Framework 是常見實作工具。
- SDD 的差異：Spec Kit 的 spec.md 並不要求可執行語法，而是以自然語言寫出 AI 代理可直接處理的規格，降低工具鏈的複雜度。
推薦書籍與文章
- The Cucumber Book（Matt Wynne & Aslak Hellesøy）— BDD 實踐的經典入門書
- Specification by Example（Gojko Adzic）— 以範例驅動需求的完整方法論，與 SDD 理念高度重疊
- User Story Mapping（Jeff Patton）— 協助團隊以視覺化方式整理需求，有助撰寫高品質 spec.md
- GitHub Blog 系列文章：AI & ML 分類 — 持續追蹤 GitHub 在 AI 輔助開發領域的最新實踐
specify CLI 指令速查表
以下為 Spec Kit 提供的 specify CLI 常用指令，可在終端機快速查閱。
- specify init — 初始化專案，建立
.specify/目錄結構與預設模板 - specify new <feature-name> — 為指定功能建立新的 spec.md、plan.md、tasks.md 骨架
- specify list — 列出目前專案中所有已建立的功能規格
- specify status — 顯示各功能規格的當前進度與完成狀態
- specify validate — 驗證 spec.md 格式是否符合模板規範，提早發現缺漏欄位
- specify upgrade — 將本地模板同步至最新官方版本，保留自訂設定
- specify export — 將規格文件匯出為 Markdown 或 JSON，方便整合進 CI 流程
在任何指令後加上 --help 可取得該指令的詳細說明與可用選項，例如 specify new --help。
spec.md 模板說明
每個功能的核心文件是 spec.md，位於 .specify/features/<feature-name>/spec.md。標準模板包含以下必要區塊：
- Feature（功能名稱）：一行簡短描述，作為 AI 代理辨識功能的唯一標題
- Goal（目標）：說明此功能對使用者或系統的具體價值，避免描述實作細節
- Background（背景）：提供必要的前置條件與情境說明，讓代理理解功能所處脈絡
- Scenarios（情境）：以 Given / When / Then 結構列出關鍵使用情境，至少涵蓋正常路徑與邊界案例
- Acceptance Criteria（驗收條件）：列出可驗證的完成標準，供 tasks.md 分解任務時對應
- Out of Scope（範圍外）：明確排除哪些功能，防止代理越界實作
撰寫 spec.md 時，「驗收條件」欄位最為關鍵。條件越具體，AI 代理產生的任務清單就越精準。建議每條驗收條件以「系統應能…」或「使用者可以…」開頭，維持一致的撰寫風格。
constitution.md 範本
constitution.md 是整個專案的技術原則宣言，位於 .specify/memory/constitution.md。它告訴 AI 代理整個專案的架構決策、技術棧選擇與禁止事項，確保每個功能的實作都與整體方向一致。
典型的 constitution.md 範本涵蓋以下區塊：
- Tech Stack（技術棧）：列出使用的程式語言、框架、資料庫與主要相依套件版本
- Architecture Principles（架構原則）：例如「優先使用函式式風格」、「禁止直接操作 DOM，統一透過 state 管理」
- Naming Conventions（命名慣例）：變數、函式、檔案與資料夾的命名規則
- Testing Strategy（測試策略）：說明單元測試、整合測試的覆蓋率目標與所用工具
- Off-limits（禁止事項）：明確列出代理不得修改的目錄、不得使用的套件或反模式
- Review Checklist（審查清單）：PR 合併前必須確認的項目，可直接對應 CI 檢查步驟
最佳實踐：每次引入重大架構決策或重構後，記得同步更新
constitution.md。過時的 constitution 比沒有 constitution 更危險，因為它會誤導 AI 代理產生不一致的程式碼。
社群與討論資源
Spec Kit 仍是相對新的工具，社群正在快速成長。以下是目前最活躍的討論管道：
- Reddit r/ClaudeCode — Spec Kit 與 Claude Code 整合討論
- Reddit r/vibecoding — 實際使用心得分享
- GitHub Discussions（官方討論區） — 提問與功能建議的官方管道，也可搜尋他人遇到的相似問題
- GitHub Issues — 回報 Bug 或追蹤已知問題的最佳入口
參與社群時，分享你的 spec.md 範例往往比描述問題更有效。具體的文件範本能讓其他成員快速理解你的情境，也更容易獲得有建設性的回饋。