新增簡單 SDD 技能

.agents/skills/simple-sdd/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: simple-sdd
+description: simple sdd workflow for coding tasks. use when the user says 提案, 實作, or 歸檔 for a development request, or asks to follow a lightweight sdd process before coding. enforce proposal before implementation, wait for confirmation, complete one task at a time, report after each small step, and archive completed sdd work.
+---
+
+# Simple SDD
+
+核心規矩只有一條：「動手寫程式之前，先把要做什麼寫清楚」。
+
+## 通用規則
+
+- 寫完要讓使用者確認，使用者同意了才開始寫。
+- 每做完一小步就回報。
+- 不要一次把所有東西做完。
+- 不要一個對話想把所有功能做完；一次做一個就好。
+- 不要自己加使用者沒要求的功能，也不要過度設計。
+- 沒把握的地方就問使用者，不要用猜的。
+- 整個流程分三個階段：提案 → 實作 → 歸檔。使用者會用這三個詞告訴你現在做哪一階段。
+
+## 階段一：提案
+
+當使用者說「提案」並描述一個需求時：
+
+1. 幫這個需求取一個英文短名稱，小寫、用連字號連接，例如 `add-todo`、`fix-login`。
+2. 判斷它是哪一種：新功能 / 修 bug / 重構，三選一。
+3. 在目前的專案資料夾，也就是現在的工作目錄底下，建立檔案：`sdd/<短名稱>/proposal.md`，內容包含：
+   - `## 為什麼做`：這個需求想解決什麼問題
+   - `## 要改什麼`：會新增或改動哪些行為，用條列
+   - `## 影響範圍`：大概會碰到哪些檔案，包含新增的、要改的
+4. 再建立檔案：`sdd/<短名稱>/tasks.md`，把工作拆成一條一條可以打勾的小步驟，每一條前面用 `- [ ]`。
+   - 每一條要小到 1 小時內能做完。
+   - 整份不要超過 10 條；如果超過，代表這個需求太大，提醒使用者先拆小一點。
+5. 在 `tasks.md` 最後加一段 `## 驗收條件`，用白話的「情境」描述「做完之後應該長怎樣」，格式如下：
+   - 情境：當使用者點擊「新增」按鈕，就把輸入框的文字加到清單最下面
+   - 情境：當輸入框是空的就按新增，就不新增，並提示「請先輸入內容」
+
+這就是驗收標準，之後要照這個自我檢查。寫完這兩個檔案後，把重點貼給使用者看，然後停下來等使用者確認。除非使用者說「開始實作」，否則不要寫任何程式。
+
+## 階段二：實作
+
+當使用者說「實作」時：
+
+1. 先讀 `sdd/<短名稱>/proposal.md` 和 `tasks.md` 這兩個檔案，搞清楚要做什麼。
+2. 從上到下，一次只做 `- [ ]` 裡的一條任務。每做一條之前，先看看專案裡有沒有現成的東西可以重複使用，不要重複造輪子。
+3. 做完一條之後，在打勾之前回頭再讀一次那條任務和「驗收條件」，確認真的做到了、沒有漏。確認沒問題就把該條的 `- [ ]` 改成 `- [x]`。改完後再看一眼 `tasks.md`，確認那一行真的從 `- [ ]` 變成 `- [x]` 了。
+4. 每完成一條就簡短回報「第幾條完成」，然後做下一條。
+5. 如果做到一半發現規格漏了東西或方向不對，停下來告訴使用者，等使用者決定，不要自己亂改規格、也不要硬幹。
+6. 全部打勾後，告訴使用者「全部完成」，並請使用者驗收。
+
+## 階段三：歸檔
+
+當使用者驗收沒問題、說「歸檔」時：
+
+1. 打開 `sdd/<短名稱>/tasks.md`，確認每一條都是 `- [x]`。如果還有沒打勾的，先告訴使用者，不要直接歸檔。
+2. 確認都完成後，把整個 `sdd/<短名稱>/` 資料夾移動到 `sdd/archive/<今天日期>-<短名稱>/`，日期格式 `YYYY-MM-DD`。
+3. 回報歸檔完成，並用一句話總結這次做了什麼，方便使用者以後回頭查。