規格驅動開發 (SDD) — 引導模式
使用者永遠不需要知道 SDD 流程。您來推動它：在每一次互動中，您要找出專案目前的位置，盡可能獨立完成所有工作，只詢問您無法推斷的事項，並在最後告訴使用者下一步確切會發生什麼。
每個功能都依序通過 spec.md → design.md → tasks.md → 實作 → review.md。範本存放在 ${CLAUDE_PLUGIN_ROOT}/skills/slate-sdd/templates/。所有複製範本的 shell 指令都以 T="${CLAUDE_PLUGIN_ROOT}/skills/slate-sdd/templates"; 開頭（下方的程式碼片段使用 $T）。
循環（每次使用此技能時執行）
- 偵測狀態（參閱狀態偵測）。靜默執行 — 讀取檔案，不要問使用者他們在哪裡。
- 吸收輸入。 不論使用者傳送了什麼 —
task.md路徑、貼上的文件、一句話、「繼續」、「好」 — 都將其對應到當前步驟（參閱處理輸入）。 - 自行完成該步驟的工作。 根據您已知的資訊起草文件：輸入內容、
docs/PRODUCT.md、docs/PRINCIPLES.md、docs/ARCHITECTURE.md、docs/GLOSSARY.md以及程式碼本身。檢查程式碼庫，而不是詢問那些程式碼就能回答的事情（技術堆疊、指令、檔案路徑、現有模式）。根據寫作風格撰寫每份文件，並在展示文件前執行其自我檢查。 - 僅詢問有缺口的部分（參閱提問）。永遠不要問您已經有合理信心草擬好的事項 — 展示它並讓使用者修正。
- 以指南區塊結束（參閱指南區塊）。每個回覆都以此結尾，沒有例外。
使用使用者書寫的語言與他們交談。使用專案現有文件所使用的語言撰寫文件（如果還沒有文件，則使用英文，除非使用者另有要求）。
狀態偵測
按此順序檢查，並在第一次匹配時停止：
| # | 條件 | 當前步驟 |
|---|---|---|
| 1 | 無 docs/PRODUCT.md 或 docs/PRINCIPLES.md | 設定 — 專案文件 |
| 2 | PRODUCT.md/PRINCIPLES.md 仍包含 [placeholder] 文字 | 設定 — 完成填寫 |
| 3 | 使用者傳送了新的工作（檔案、文字、想法），但不是當前活躍的功能 | 分類 新的工作 |
| 4 | 活躍功能具有 status: draft 的 spec.md | 規格 |
| 5 | spec.md 已批准，design.md 缺失或 status: draft | 設計 |
| 6 | design.md 已批准，tasks.md 仍有範本佔位符 | 任務（規劃） |
| 7 | tasks.md 有任何 T 不是 done | 實作 — 下一個 T |
| 8 | 所有 T 完成，review.md status: pending | 審查 |
| 9 | review.md 已批准 / 已批准附註 | 關閉 — 記憶 + 狀態，然後提供下一個功能 |
活躍功能 = 在 docs/MEMORY.md → 目前狀態 → 進行中 中命名的功能；如果那個為空，則為 docs/specs/ 中編號最高且其 review.md 尚未批准的 NNN-*。如果有多個是開放的且使用者沒有指定一個，則詢問是哪個（一個問題，列出它們）。
快速讀取狀態的方法：
ls docs/ docs/specs/ 2>/dev/null
grep -H '^status:' docs/specs/*/*.md 2>/dev/null
grep -H -- '- \*\*Status:\*\*' docs/specs/*/tasks.md 2>/dev/null
處理輸入
- 一個
task.md（或任何 .md/.txt）的路徑 — 完整讀取它。將其視為原始需求，而不是一個完整的tasks.md：收集問題、行為、範例、邊界情況、限制、檔案提示。然後進行分類。 - 貼上的文字或一行想法 — 同上。
- 「continue」/「próximo」/「ok」/「aprovado」/「pode seguir」 — 如果當前文件正在等待批准，這表示批准：設定其
status並在同一個回覆中移動到下一個步驟。否則，只需執行當前步驟。 - 修正或回答 — 將其應用於當前文件，更新它所解決的任何
Q，重新檢查缺口，繼續。 - 關於流程的問題 — 簡短回答，然後以指南區塊繼續。
分類（新工作）
決定規模並在一行中說明您的決定：
- 小型 — 明顯、可逆、約 1-3 個檔案，無設計選擇（錯字、小錯誤、設定變更）。僅建立
tasks.md（在docs/specs/NNN-name/中），填寫它，然後直接進入實作。跳過規格/設計/審查，除非使用者想要它們。 - 功能 — 任何需要定義行為或做出設計選擇的事項。執行完整流程。
- 需要研究 — 一個關鍵選擇確實未知（函式庫、方法、供應商）。完整流程加上在設計前的
research.md。
當在小型和功能之間猶豫時，選擇功能，並告知使用者他們可以要求捷徑。
然後建立資料夾：
- 下一個編號 =
docs/specs/中最高的NNN-+ 1（從001開始）。名稱 = 從輸入中取的短 kebab-case 名稱；不要詢問它。 - 複製範本：
D=docs/specs/NNN-feature-name; mkdir -p "$D"
cp $T/specs/spec.md $T/specs/design.md $T/specs/tasks.md $T/specs/review.md "$D"/
# 僅在需要研究時：
cp $T/specs/research.md "$D"/
- 立即將從輸入中收集到的所有內容放入正確的文件中：問題/AC/限制/範圍外 →
spec.md；實作提示和檔案路徑 → 保留作為design.md/tasks.md的註記（不要遺失它們；一旦到達相關部分就將它們添加到其中）。 - 更新
docs/MEMORY.md→ 目前狀態 → 進行中，填入功能 ID 和步驟。 - 在同一個回覆中直接繼續執行規格步驟。
步驟
設定
mkdir -p docs/decisions docs/specs
for f in PRODUCT PRINCIPLES ARCHITECTURE GLOSSARY MEMORY; do [ -f docs/$f.md ] || cp $T/$f.md docs/$f.md; done
[ -f docs/decisions/0000-template.md ] || cp $T/decisions/0000-template.md docs/decisions/
[ -f CLAUDE.md ] || cp $T/CLAUDE.md CLAUDE.md
永遠不要覆蓋現有檔案。然後在詢問任何事之前從儲存庫預先填入：讀取 package.json / pyproject.toml / go.mod / Cargo.toml / Makefile / CI 檔案 / README 來填寫技術堆疊、指令、目錄對應和元件。僅詢問程式碼無法告訴使用者的事項：產品是什麼、為誰而做、目標、非目標、業務規則、團隊規則。如果使用者是帶著一個功能來的，保持設定簡短（PRODUCT + PRINCIPLES 必要內容）並繼續處理功能；ARCHITECTURE 和 GLOSSARY 可以稍後逐步填寫。
規格
根據輸入填寫 spec.md。每個 AC 必須是 Given/When/Then 格式且可獨立測試 — 自行將模糊的需求改寫成 AC 並展示它們。每個阻礙設計的未知事項變成一個 Q [blocking]；較小的未知事項變成 Q [non-blocking]，並附上您建議的答案。呈現一個簡短摘要（問題、AC、範圍外、開放的 Q）並請求批准。門檻： 僅在沒有 blocking 的 Q 是開放的且使用者已批准（或告訴您無需詢問即可繼續）時才開始設計 → 設定 status: approved。
設計
讀取 docs/PRINCIPLES.md 和 docs/ARCHITECTURE.md，並檢查涉及的程式碼路徑。自行草擬完整的 design.md；涵蓋每個 AC（說明哪個部分涵蓋哪個）。自行做區域性決定為 D 條目並附上理由；僅將那些代價高昂無法逆轉或屬於偏好的決定帶給使用者，每個決定附上您的建議。一個影響整個專案的決定 → 在 docs/decisions/ 中提議一個 ADR。顯示一個簡短摘要並請求批准。門檻： 與規格相同。
任務
根據規格 + 設計填寫 tasks.md：以依賴順序排列的小型 T，每個都包含 涵蓋範圍、檔案，以及一個來自 PRINCIPLES.md → 指令的實際驗證指令。每個 AC 至少由一個 T 涵蓋；每個邊界情況 E 都有一個測試。除非使用者要求，否則沒有批准門檻 — 顯示任務清單並移動到實作。
實作
一次一個 T：設定 in-progress，實作，執行其驗證，設定 done（或 blocked 並附上原因）。每個 T 之後，用 2-3 行回報並繼續下一個，除非某些事情失敗、T 與 PRINCIPLES.md 衝突，或完成需要範圍外中的事項 — 那麼就停止並詢問。保持 docs/MEMORY.md → 進行中 指向當前的 T。
審查
填寫 review.md：實作報告、每個 AC 的結果和證據、執行完整的測試/lint/建置指令、應用 PRINCIPLES 審查檢查清單、列出發現。根據寫作風格檢查功能文件。將每個違規記錄為一個 minor 發現。呈現判定。如果使用者同意，修正 blocker/major 發現，然後重新審查。
關閉
將持久性的經驗教訓移動到 docs/MEMORY.md，更新目前狀態（已完成 += 此功能，進行中 清除），將能力添加到 PRODUCT.md → 能力，從後續事項創建任何 ADR。然後提供下一個項目（來自 下一步、審查的後續事項，或「發送給我下一個任務」）。
提問
- 每次輪流最多問 3-5 個問題，最重要的在先。編號、簡短。
- 每個問題都附帶您建議的答案，這樣使用者可以回覆「ok」/「1 ok, 2 não」而不是書寫：
1. 過期的連結應該顯示錯誤頁面嗎？→ 建議：是的，附帶一個「重新發送」按鈕。 - 當
AskUserQuestion工具可用且答案是在幾個選項中選擇時，使用它，並將推薦選項放在第一位。 - 永遠不要問程式碼、文件或輸入已經回答的問題。永遠不要問使用者下一步該做哪個 SDD 步驟 — 那是您的工作。
- 如果使用者說「你決定」/「tanto faz」/「pode seguir」，採用您的建議，記錄它們（作為
Q → answer或D），然後繼續。
指南區塊
每個回覆都以這個區塊結尾（使用使用者的語言），這樣使用者永遠不需要思考下一步要做什麼：
---
📍 功能: NNN-feature-name · 步驟: 規格 (2/6) [設定 · 規格 · 設計 · 任務 · 實作 · 審查]
✅ 現在已完成: <一行>
❓ 我需要您提供: <編號問題，或「無」>
➡️ 下一步: <使用者回覆後確切會發生什麼事 — 例如「回覆 'ok' 以批准規格，我將開始撰寫設計」>
如果不需要使用者提供任何東西，請告知並說明在「繼續」後您將做什麼。
指南區塊和聊天訊息不需要完整的寫作風格自我檢查。保持它們簡短直接。
文件規則
- 替換每個
[placeholder]、NNN和YYYY-MM-DD。一個空的段落變成None.— 永遠不要刪除標題。 - 使用 ID（
AC、Q、D、T、E、F）在文件之間交叉引用，而不是複製文字。 - 在撰寫
design.md之前以及實作任何任務之前，讀取docs/PRINCIPLES.md。 - 如果需求不清楚，添加一個
Q並提問，而不是猜測。如果任務與PRINCIPLES.md衝突，停止並詢問。 - 每個事實存於一份文件中；其他文件指向它。
寫作風格（每份文件）
下一個模型會讀取這些文件並根據它們執行。撰寫時要讓每個句子只有一個含義。這些規則適用於每種語言。
清晰度 & 精確性（靈感來自 ASD-STE100）
- 一個句子一個想法。 指令最多使用 20 個字。描述最多使用 25 個字。
- 一個句子一個指令。 對動作使用祈使句。寫「回傳
404。」不要寫「系統可能應該回傳 404。」 - 主動語態、現在式。 指名執行者：使用者、系統或一個元件的名稱。
- 一個詞彙 = 一個意義。 使用來自
docs/GLOSSARY.md的準確詞彙。不要為同一個概念使用同義詞。當您使用一個新的領域詞彙時，將該詞彙添加到GLOSSARY.md。 - 需求關鍵字： 僅使用 must / must not / may（必須 / 不得 / 可以）。不要使用「應該」、「理想上」、「嘗試」、「如果可能」（「deveria」、「idealmente」、「tentar」、「se possível」）。
- 量化。 用數字、單位或可觀察的結果取代每個模糊的詞。不要使用沒有數字的這些詞：快、慢、許多、少數、大、小、穩健、容易、簡單、適當、使用者友善、一些、「等等」、「以此類推」（rápido、lento、muitos、poucos、grande、robusto、fácil、adequado、alguns、「etc.」）。
- 錯誤：「頁面載入很快。」正確：「頁面在 2 秒內（p95）載入。」
- 沒有成語、隱喻、笑話、填充詞或行銷語氣。
- 沒有不明確的代名詞。 如果「它」、「這個」或「那個」（「ele」、「isso」、「este」）可以指代兩個名詞，重複該名詞。
- 結構重於散文。 優先使用清單和表格。一個段落最多 3 個句子。
code中的準確名稱。 使用反引號撰寫識別碼、路徑、指令、欄位和值。不要改寫它們。
第一原則
- 從事實開始。 習慣和類比不是理由。「其他專案做 X」不是理由。
- 標記每個重要主張：
- 事實 — 已驗證。給出來源：檔案路徑、指令輸出、資料或文件。
- 假設 — 未驗證。撰寫如何驗證它。
- 決定 — 一個選擇。給出理由，源自事實或限制。
- 追溯每個決定 到一個問題、一個
AC或一個限制。如果一個決定沒有追溯，移除它。 - 需求先於解決方案。 按此順序撰寫：問題 → 限制 → 滿足它們的最簡單解決方案。
- 最簡單選項優先。 選擇滿足所有 AC 的最簡單選項。每個新增的元件、依賴項或步驟都需要一個陳述的理由。
自我檢查（在展示文件之前執行）
- 沒有遺留
[placeholder]、NNN或YYYY-MM-DD。 - 規則 5 和 6 中的禁止詞彙沒有遺留。
- 每個句子都在規則 1 的字數限制內。
- 每個領域詞彙都在
docs/GLOSSARY.md中。 - 每個
D和每個決定都有一個理由。 - 每個未經驗證的主張都標記為假設並有一個驗證方法。
參考
範本在 $T = ${CLAUDE_PLUGIN_ROOT}/skills/slate-sdd/templates/ 中：
PRODUCT.md、PRINCIPLES.md、ARCHITECTURE.md、GLOSSARY.md、MEMORY.md、CLAUDE.md— 專案層級，建立一次。decisions/0000-template.md— 每個專案層級決定一個 ADR。specs/spec.md、design.md、tasks.md、review.md、research.md— 每個功能一套。