Menü
修復 Bug 後從 Git diff 自動擷取修復細節並更新 Notion 任務追蹤頁面（僅限 bug 型任務）。當使用者提到 /bug-close、「關閉 bug」、「bug 結案並補修復細節」時觸發此 Skill。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
CREW 環境健診 —— 一次性檢查 CREW 所有必要與選配依賴（Node/Git/Notion MCP/Agent Teams/瀏覽器 MCP/config/專案註冊/CLAUDE.md），列出綠黃紅燈與修法。當使用者提到 /crew-doctor、「CREW 環境健診」、「CREW 為什麼不能用」時觸發此 Skill。
瀏覽與探索已有的 .spec/ 規劃文件 —— 深度閱讀、跨任務比較、模式搜尋。當使用者提到 /plan-browse、「瀏覽 .spec 規劃」、「看之前的規劃設計」時觸發此 Skill。
從 .spec/{slug}/plan.md 以 Agent Teams leader-delegate 模式產生程式碼，含退出驗證與錨點有效性檢查，Leader 只協調不寫 code。當使用者提到 /plan-build、「從 spec 產生程式碼」、「plan-build 產碼」時觸發此 Skill。
結案前先跑文件漂移硬關卡（FAIL 擋、WARN 需明示放行），通過後蓋章 verified_at_commit、提交 Git、批次同步 plan.md 與 deploy.sql 到 Notion。當使用者提到 /plan-close、「feature 結案」、「同步 spec 到 Notion 並結案」時觸發此 Skill。
智慧推薦 CREW 當前任務下一步 —— 呼叫 crew-state.py 讀 state.json 算出下一個 /plan-* 指令並轉成人話。當使用者提到 /plan-next、「CREW 下一步指令」、「這個 spec 接下來做什麼」時觸發此 Skill。
CREW 規劃 —— spec / db / arch 三個 pass 把決策與驗收條件寫進 .spec/{slug}/plan.md，DB 設計另產 deploy.sql（零 Notion 呼叫）。當使用者提到 /plan、「CREW 完整規劃」、「一次跑完 spec/db/arch」時觸發此 Skill。
| name | bug-close |
| description | 修復 Bug 後從 Git diff 自動擷取修復細節並更新 Notion 任務追蹤頁面（僅限 bug 型任務）。當使用者提到 /bug-close、「關閉 bug」、「bug 結案並補修復細節」時觸發此 Skill。 |
修復 Bug 並 commit 後，從 Git 自動擷取修改資訊，更新 Notion「任務追蹤工具」的 Bug 頁面，並在「Bug 知識庫」同步建立精簡條目。
/bug-start 建立 Bug 條目（Notion「任務追蹤工具」中有狀態為「進行中」的 🐞 錯誤條目）前置檢查：參照 plugin 根目錄
references/prerequisites.md（相對 SKILL.md 為../../references/）執行完整前置檢查（CLAUDE.md + 設定檔 + 專案註冊）。
依序執行以下指令：
# 當前分支
git branch --show-current
# 最近 10 筆 commit（供使用者選擇範圍）
git log --oneline -10
# 預設取最近 1 個 commit 的變更
git diff HEAD~1..HEAD --stat
# 完整 diff（用於摘要化）
git diff HEAD~1..HEAD
若使用者指定 commit 範圍（如 HEAD~3..HEAD），使用指定的範圍。
結案前，若偵測到修復在 feature branch 上進行（同時滿足：當前分支是 Bug 的修復分支、屬於 feature/hotfix 分支、能取得 DEV 分支名稱），引導使用者 merge 回開發分支；條件不滿足或使用者選擇跳過則直接進入原有結案流程。完整判斷條件、互動式引導文案、執行步驟見 plugin 根目錄 references/merge-guide.md（相對 SKILL.md 為 ../../references/）。
搜尋 Notion「任務追蹤工具」（Data Source ID 見設定檔）中符合條件的條目：
使用 notion-search 搜尋：
同時取得 Git Repo 識別碼（從 git remote get-url origin 解析），用於輔助篩選同一專案下的 Bug。
優先匹配邏輯：
/bug-start 建立結案前執行 4 項檢查，確保修復品質達標：
| # | 檢查項 | 驗證方式 | 失敗處理 |
|---|---|---|---|
| C1 | 根因分析已填寫 | Notion 頁面「根因分析」區塊非空 | WARN：提醒補填，允許繼續但狀態強制為「測試中」 |
| C2 | 修復 commit 存在 | git log --oneline -10 中有相關 commit | BLOCK：必須先 commit |
| C3 | 迴歸測試存在 | grep -rF "Regression: {Bug 標題}" --include="*Test.java" --include="*.test.*" --include="*.spec.*" .（{Bug 標題} = Notion 頁面標題，需與 /bug-fix 產出的 attribution 註解 // Regression: {Bug 標題} 用字完全一致；grep 需在專案根目錄執行） | WARN：建議用 /bug-fix 產出 |
| C4 | 驗證項目至少一項勾選 | Notion 頁面 checkbox 狀態 | WARN：提醒驗證 |
驗證結果顯示：
退出驗證：
✅ C1 根因分析已填寫
✅ C2 修復 commit 存在（abc1234）
⚠️ C3 無迴歸測試
⚠️ C4 驗證項目未勾選
結論：可結案，建議處理 C3 和 C4
若 C1 為 WARN → 目標狀態選項中移除「已完成」，只能選「測試中」。
詢問使用者（若未在初始輸入中提供）：
邏輯錯誤 / 資料異常 / 設定問題 / 第三方API / 效能 / 權限 / 前端UI測試中（預設）或 已完成根據 git diff 自動產出以下內容：
修改檔案清單：從 --stat 擷取，格式化為列表
修改說明：根據 diff 內容，以分層架構摘要（如 Java 專案的 Controller / Service / DAO 層）
修改後程式碼：擷取關鍵的程式碼變更片段（不超過 50 行）
使用 notion-update-page 更新條目：
Properties 更新：
| 欄位 | 值 |
|---|---|
| 狀態 | 使用者選擇（預設「測試中」） |
| 根因分類 | 使用者選擇的分類 |
| 修復分支 | 當前 Git branch（若原本為空） |
Content 更新：
使用 update_content 指令，搜尋模板中的空白區塊並填入：
「根因分析」區塊：
「修復方案」區塊：
在「Bug 知識庫」資料庫建立一筆精簡條目（Data Source ID 見設定檔）：
| 欄位 | 值 |
|---|---|
| Name | Bug 標題 |
| Tags | 根據 bug 內容自動推測相關標籤 |
| 難易度 | 根據修改檔案數和 diff 行數判斷：≤3 檔案且 ≤50 行 → 普通(2~4h)，否則 → 困難(4~6h) |
| 專案資料庫 | 同一專案 |
| 參考連結 | 任務追蹤工具的頁面 URL |
頁面內容為精簡版：
**根因**：{根因說明}
**解法**：{修復摘要，2-3 句話}
**關鍵程式碼**：
（修改前後的關鍵差異）
若設定檔中「Bug 知識庫」ID 為空，則跳過此步驟。
AI 分析本次 bug 的根因、修復和調查過程，判斷是否有可複用的洞察。
| 類型 | 說明 | 範例 |
|---|---|---|
| pattern | 可複用的 bug 模式 | 「此專案的 token 過期 bug 常發生在推播模組」 |
| pitfall | 應避免的陷阱 | 「LINE API 的 503 需要特別處理，不能只處理 401」 |
| architecture | 架構層面的洞察 | 「PushService 和 TokenService 的耦合度太高」 |
| environment | 環境相關的知識 | 「正式環境的 LINE API rate limit 是 100 req/min」 |
寫入 ~/.claude-company/bug-workflow/learnings/{project-slug}.jsonl：
{
"date": "2026-04-24",
"skill": "bug-close",
"bug_title": "推播排程發送失敗",
"root_cause": "LINE API refresh 回傳 503 未處理",
"pattern": "third-party-api",
"type": "pitfall",
"insight": "LINE API 的 refresh token 端點偶爾回傳 503，retry 邏輯必須涵蓋 503 且加入 exponential backoff",
"confidence": 9,
"files": ["PushService.java"],
"notion_url": "https://www.notion.so/xxx"
}
project-slug 來自 Git Repo 識別碼（/ 替換為 -）。每行一筆 JSON（JSONL 格式）。
AI 自動判斷是否有學習價值：
mkdir -p ~/.claude-company/bug-workflow/learnings
若目錄不存在，首次使用時自動建立。
把 .spec/{slug}/state.json 的 close 步驟標為完成（見 ../../references/state-discipline.md）：
python3 "${CLAUDE_PLUGIN_ROOT}/scripts/crew-state.py" set \
--slug {slug} --step close --status done
標記後 /plan-next 與 SessionStart 開場提醒就不會再把它列為未結案。
🔴 不要刪除 state.json。舊版的 handoff.md 是純過程性檔案、結案即刪；state.json
是任務的結案紀錄，要保留並入版控 —— /plan-deploy-confirm 事後要靠它查
steps.close.status 與 deploy 的執行進度，刪掉就查不到「這個任務的 SQL 到底跑了沒」。
與下方回傳結果的 Git 分支清理提示同屬結案收尾動作。
向使用者回傳：
Bug 已結案！後續事項：
{若有 merge} • git push origin {dev_branch} — 推送合併結果
• 驗證完成後請在 Notion 頁面勾選驗證項目
• 若上線後問題復發，可使用 /bug-update reopen 重新開啟
{若 feature branch 不再需要} • git branch -d feature/xxx — 清理分支
close 組 —— 本 skill 只結 bug 型任務；feature/.spec 任務結案用 /plan-close。
/plan-close/bug-updatemcp-atlassian）或 jira-from-pm/bug-startupdate_content 的搜尋模式會匹配失敗。遇到這種情況，改用 replace_content 重寫整個頁面內容（先讀取現有內容合併）。git diff 遇到圖片、Excel 等二進位檔案會顯示 Binary files differ，不要把這些納入「修改後程式碼」區塊。只擷取文字類檔案的 diff。git log --oneline -10 中混有非修復用途的 commit，應先確認正確範圍再擷取 diff，不要盲目用 HEAD~1..HEAD。dev_branch，但 bug-close 是 bug-workflow 的 skill。讀取失敗時顯示簡化提示，不阻擋流程。/bug-close。git push，因為 push 會影響遠端共享狀態，需使用者明確操作。參考 examples/good-closure-report.md 了解理想的結案報告結構和品質。
/bug-setup 完成初始設定git checkout {dev_branch}（git 會自動從 remote tracking 建立本地分支），若失敗則 git fetch && git checkout {dev_branch}