Menü
在 Notion 任務追蹤工具建立 Bug 條目並填入標準化模板（僅建條目，不含 .spec/ 目錄與 Git branch）。當使用者提到 /bug-start、「建立 bug 條目」、「記錄 bug 到 Notion」、「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-start |
| description | 在 Notion 任務追蹤工具建立 Bug 條目並填入標準化模板（僅建條目，不含 .spec/ 目錄與 Git branch）。當使用者提到 /bug-start、「建立 bug 條目」、「記錄 bug 到 Notion」、「bug 通報」時觸發此 Skill。 |
| argument-hint | <問題簡述> [環境] [優先順序] |
在 Notion「任務追蹤工具」資料庫建立一筆 Bug 條目，自動填入標準化頁面模板，並關聯對應專案。
前置檢查：參照 plugin 根目錄
references/prerequisites.md（相對 SKILL.md 為../../references/）執行完整前置檢查（CLAUDE.md + 設定檔 + 專案註冊）。
使用者會以以下格式觸發：
/bug-start <問題簡述>
從使用者輸入中擷取：
取得 branch 名稱、當前工作目錄與 Git Repo 識別碼：
# 分支名稱
git branch --show-current 2>/dev/null || echo ""
# 當前工作目錄
pwd
# Git 遠端 URL（用於自動對應 Notion 專案）
git remote get-url origin 2>/dev/null || echo ""
Git Repo 識別碼解析規則：
從 git remote get-url origin 取得遠端 URL 後，解析為識別碼：
intumit（公司 GitLab）→ 只取 {group}/{repo}，例如 ORG01P2401/PushAPIService{host}/{group}/{repo}，例如 github.com/mark22013333/crew.git 後綴，支援 HTTPS / SSH 格式自動專案對應邏輯：
git remote get-url origin 取得 Git 遠端 URLintumit → {group}/{repo}，其他 → {host}/{group}/{repo}，去除 .git 後綴）若設定檔中無對應，也可用 notion-search 搜尋 Notion「專案資料庫」（Data Source ID 見設定檔），找「Git Repo」欄位與識別碼匹配的專案。
若使用者未在初始輸入中提供以下資訊，依序詢問：
測試 / UAT / 正式高 / 中 / 低使用者可在初始輸入中直接指定，例如：
/bug-start SSO登入找不到使用者 正式 高
在建立 Notion 條目前，自動偵測負責人以填入「負責人」（people 類型）欄位：
git config user.email 2>/dev/null || echo ""
notion-get-users 取得 Notion 工作區使用者列表注意：
notion-get-users回傳的使用者物件包含id、name、person.email等欄位。比對時使用person.email。
使用 notion-create-pages 在「任務追蹤工具」資料庫建立新條目：
Data Source ID：從設定檔的「任務追蹤工具」取得
Properties：
| 欄位 | 值 |
|---|---|
| 任務名稱 | 使用者提供的問題簡述 |
| 任務類型 | ["🐞 錯誤"] |
| 狀態 | 進行中 |
| 優先順序 | 使用者選擇（預設「中」） |
| 環境 | 使用者選擇（預設「正式」） |
| 修復分支 | Git branch 名稱（若有） |
| 專案資料庫 | 關聯的專案頁面 URL |
| 負責人 | 「偵測負責人」一節偵測到的 Notion 使用者（若有） |
頁面的 content 使用以下標準模板：
## 🔴 問題描述
- **通報來源**：
- **發生時間**：{當前日期時間}
- **重現步驟**：
1. ...
2. ...
- **預期行為**：
- **實際行為**：
- **錯誤截圖**：
---
## 🔍 調查過程
### 關鍵 Log
### 相關 SQL 查詢
### 初步判斷
---
## 🧠 根因分析
- **問題根因**：
- **問題檔案**：
- **問題程式碼**：
---
## ✅ 修復方案
- **修改檔案清單**：
- **修改說明**：
- **修改後程式碼**：
- **修復 Commit**：
- **修復分支**：
---
## 🧪 驗證
- [ ] 本地測試通過
- [ ] UAT 驗證通過
- [ ] 正式環境確認
- [ ] 通報者確認問題已解決
---
## 📝 經驗教訓
- **學到什麼**：
- **如何預防**：
若使用者在初始輸入中已提供問題描述內容，將其預填入「問題描述」區塊的「實際行為」欄位。
建立 Notion 頁面後，自動收集環境資訊寫入「調查過程」區塊。
git log --oneline -5
2–4. 環境狀態／知識庫快速搜尋／學習快速搜尋：與 /bug-investigate 共用收集指令，參照 plugin 根目錄 references/evidence-collection.md（相對 SKILL.md 為 ../../references/）「共用收集項目」段。
使用 notion-update-page 的 update_content，在「調查過程」區塊寫入，標題為「### [HH:mm] 初始環境快照」，先列本 skill 專屬的「最近 5 筆 commit」，再接 references/evidence-collection.md「共用 Notion 寫入格式」段的三段共用區塊：
### [HH:mm] 初始環境快照
**最近 5 筆 commit**：
- abc1234 fix: 修正推播排程的 cron 表達式
- def5678 feat: 新增推播統計 API
- ...
（接續共用區塊：環境狀態／歷史參考／歷史學習，見 references/evidence-collection.md）
參照 references/evidence-collection.md「不阻擋流程」段。
建立 Bug 條目後，嘗試在同一資料庫中找到相關的 Feature 條目，透過「相關任務」self-relation 建立關聯（依 SRS 編號／功能模組名擷取關鍵字，查詢同專案 Feature 並比對標題，成功則 patch「相關任務」欄位）。完整流程細節（關鍵字擷取規則、查詢 filter、標題比對邏輯、不阻擋流程）參照 plugin 根目錄 references/feature-linking.md（相對 SKILL.md 為 ../../references/）「步驟 8」段。
若步驟 8 成功關聯到 Feature，進一步讀取該 Feature 的「修復分支」欄位，驗證分支是否存在，並詢問使用者是否切換／改用此分支作為 Bug 修復分支。完整流程細節（分支存在/不存在的處理選項、不阻擋流程）參照 plugin 根目錄 references/feature-linking.md（相對 SKILL.md 為 ../../references/）「步驟 9」段。
向使用者回傳：
Bug 條目已建立！後續可使用：
• /bug-investigate — 開始調查根因（推薦下一步）
• /bug-update <內容> — 補充調查資訊（Log、SQL、判斷等）
• /bug-fix — 確認根因後修復
• /bug-close — 修復完成後結案
start 組 —— 本 skill 只建 Notion bug 條目；需完整入口（Notion + .spec/ + branch）用 /plan-start。
/plan-start（type=bug）/bug-fix/bug-update/plan-startnotion-create-pages 的 Relation 欄位需要填入「被關聯頁面的 URL」（如 https://www.notion.so/xxx），不是填專案名稱字串。填錯格式會靜默失敗，條目建立成功但 Relation 為空。["🐞 錯誤"]，不是字串 "🐞 錯誤"。用字串格式不會報錯但會建立新的標籤。ORG01P2401/sample-app 和 ORG01P2401/sample-App 是不同的識別碼。比對時使用原始大小寫，不做 case-insensitive matching。notion-update-page（patch）而非 notion-create-pages。notion-update-page 的 Relation 欄位使用 {"relation": [{"id": "..."}]} 格式，id 是 page ID 不是 URL。/bug-setup 完成初始設定/bug-setup 更新 schema