Menú
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。
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
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 後結束。