| source | ../../../../skills/spec-driven-dev/SKILL.md |
| source_version | 1.2.0 |
| translation_version | 1.2.0 |
| last_synced | "2026-03-23T00:00:00.000Z" |
| status | current |
| description | [UDS] 在撰寫程式碼前,建立、審查和管理規格文件 |
| name | sdd |
| allowed-tools | Read, Write, Grep, Glob, Bash(git:*) |
| scope | universal |
| argument-hint | [spec name or feature | 規格名稱或功能] |
規格驅動開發助手
語言: English | 繁體中文
在撰寫程式碼前,建立、審查和管理規格文件。
快速檢查清單
- 搜尋現有規格:查看
specs/、docs/specs/ 或專案規格目錄
- 決定範圍:新功能 vs 修改現有功能
- 選擇唯一的規格 ID:
SPEC-NNN 或 kebab-case 變更 ID
- 撰寫包含明確 AC(Given/When/Then 格式)的提案
- 實作前取得核准
- 依序實作任務,對照規格驗證
- 完成後歸檔規格
決策樹
新需求?
├─ 修復符合規格行為的 Bug? → 直接修復
├─ 錯字/格式/註解? → 直接修復
├─ 相依套件更新(不破壞相容性)? → 直接修復
├─ 新功能/能力? → 建立提案
├─ 破壞性變更? → 建立提案
├─ 架構變更? → 建立提案
└─ 不確定? → 建立提案(較安全)
工作流程
DISCUSS ──► CREATE ──► REVIEW ──► APPROVE ──► IMPLEMENT ──► VERIFY ──► ARCHIVE
0. Discuss - 釐清範圍
在撰寫規格前,捕捉模糊地帶、建立治理原則、解決歧義。
1. Create - 撰寫規格
定義需求、技術設計、驗收條件和測試計畫。
2. Review - 審查驗證
與利害關係人檢查完整性、一致性和可行性。
3. Approve - 核准
在實作開始前取得利害關係人簽核。
4. Implement - 實作
依據已核准的規格進行開發,參照需求和驗收條件。
5. Verify - 驗證
確保實作符合規格,所有測試通過,驗收條件已滿足。
6. Archive - 歸檔
歸檔已完成的規格,連結至 commits/PRs。
規格狀態
| 狀態 | 說明 | State | Description |
|---|
| Draft | 草稿中 | Draft | Work in progress |
| Review | 審查中 | Review | Under review |
| Approved | 已核准 | Approved | Ready for implementation |
| Implemented | 已實作 | Implemented | Code complete |
| Archived | 已歸檔 | Archived | Completed or deprecated |
規格結構
# [SPEC-ID] Feature: [Name]
## Overview
簡短描述提案變更。
## Motivation
為什麼需要這個變更?解決什麼問題?
## Requirements
### Requirement: [Name]
系統 SHALL [行為描述]。
#### Scenario: [成功案例]
[初始情境]
[執行動作]
[預期結果]
AC-1: Given [context], when [action], then [result]
[架構、API 變更、資料庫變更]
[ ] [元件] 的單元測試
[ ] [流程] 的整合測試