Menu
Bug 修復：四階段根因診斷與修復，main agent 直接修（不派 ddd-developer），產出三合一或 sprint works.md 紀錄。 獨立觸發的 hotfix 快速解時使用；xreview findings 的修正走 /ddd.xreview 流程，不用本 skill。 Trigger: "fix bug", "fix this", "bugfix", "hotfix", "修 bug", "修這個", "這裡壞了", "有 bug", /ddd.fixbug。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
E2E 除錯：用 agent-browser CLI 重現場景、觀察狀態、定位前端問題根因。 E2E 測試失敗、需要視覺驗證 UI 行為、或追蹤前端問題時使用，通常在 /ddd.work 中觸發。 Trigger: "debug E2E", "check the page", "why is the test failing", "open the browser", "take a screenshot", "inspect the DOM", "E2E 失敗", "測試壞了", "檢查頁面", /ddd.agent-browser。
前置規劃：寫 spec 前，用 PRD、TECHSTACK、既有 sprint 文件與 codebase stress-test 使用者的 idea / rough plan，沿 decision tree 逐一釐清阻塞決策。 需求模糊、方向未定、或需要 domain language / 技術方向校準時使用；需求已明確直接走 /ddd.spec；完成後 chain 到 /ddd.spec。 Trigger: "plan a feature", "plan an extension", "clarify requirements", "brainstorm", "explore ideas", "from scratch", "greenfield", "規劃擴充", "規劃改動", "規劃功能", "釐清需求", "腦力激盪", "從頭開始", /ddd.plan。
撰寫規格書：產出包含 User Story、驗收條件、Reuse Map、API 契約、ADR、輕量 Milestones 的 spec.md。 需求已明確、可直接定義驗收條件時使用；需求模糊先走 /ddd.plan。 Trigger: "write a spec", "define requirements", "draft acceptance criteria", "寫規格", "定義需求", "驗收條件", /ddd.spec。
任務拆解：將已確認 spec.md 的 Milestones 就地細化為 task 列表， 或將過大的 scope 拆成 semver-like 子編號資料夾。 spec 確認後、milestone 不夠清楚或要標平行工作線時使用；milestone 已夠清楚直接走 /ddd.work。 Trigger: "細化 milestones", "拆分 sprint", "break down tasks", "create a task list", "split into sub-sprints", /ddd.tasks。
TDD 開發執行：coordinator 逐 milestone 派 ddd-developer 以 Red → Green → Refactor 循環實作並驗收； 遇到 🔀 平行工作線時同時派發多個 worker 分工。 spec.md 已確認、準備寫程式碼時使用。 Trigger: "start implementing", "begin development", "let's code", "do TDD", "開始實作", "開始寫", "動工", /ddd.work。
Cross review：派多個獨立 AI 模型平行審查文件、規格一致性、實作與安全性，交叉比對 findings 降低單一模型盲點， 驗證高嚴重度問題後直接回報對話並提出解決方法提案。 開發完成後、commit 或 push 前使用；findings 的後續修正也在本流程內，不走 /ddd.fixbug。 Trigger: "review code", "cross review", "let's review", "check my changes", "審查程式碼", "code review", "review 一下", /ddd.xreview。
| name | ddd.fixbug |
| description | Bug 修復：四階段根因診斷與修復，main agent 直接修（不派 ddd-developer），產出三合一或 sprint works.md 紀錄。 獨立觸發的 hotfix 快速解時使用；xreview findings 的修正走 /ddd.xreview 流程，不用本 skill。 Trigger: "fix bug", "fix this", "bugfix", "hotfix", "修 bug", "修這個", "這裡壞了", "有 bug", /ddd.fixbug。 |
系統性診斷與修復 bug。強制四階段流程，禁止跳過根因分析直接猜修。
Main agent 直接修——bug 修復是探索性任務，需要與使用者即時討論假設與發現，且通常小而急，派工開銷不值得。這是唯一 main agent 直接寫 code 的 skill；例外只存在於本 skill，其他文件只引用本 skill，不重述條件。
定位：例外的快速解，與 /ddd.xreview 互斥。xreview findings 的修正屬於正式流程，由 /ddd.xreview 收集決策後派 ddd-developer 執行，不進入本 skill。
釐清問題
重現
定位根因
git log、git blame）寫預期行為測試
最小改動修復
驗證
失敗處理
更新文件
docs/ 下建 <序號>-hotfix-<簡述>/works.md（序號接續既有 docs 編號）回報使用者
獨立 hotfix 不開 sprint 文件包，以一份三合一 works.md 承擔規格與紀錄：Phase 1 與使用者對齊預期行為與根因假設後才進入修復，這就是底線第 1 條（No Code Without Docs）的輕量規格確認形式。格式如下：
# Hotfix: <簡述>
## 問題描述
- **症狀**：<使用者觀察到的現象>
- **預期行為**：<應該怎樣>
- **影響範圍**：<哪些功能/使用者受影響>
## 根因分析
- **根因**：<一句話根因>
- **定位過程**：<怎麼找到的，排除了哪些假設>
- **受影響的檔案**：<列出修改的檔案>
## 修復內容
- **修了什麼**：<具體改動>
- **測試**：<新增或修改了哪些測試>
- **驗證結果**：<測試執行結果>
修復完成、測試通過、使用者確認 commit 後結束。