kenaz 0.3.18 → 0.3.20

package/core/plugins/kenaz/skills/dev_agent/SKILL.md

@@ -1,500 +1,39 @@
 ---
 name: Dev Agent
-description: 開發協調、Pipeline管理、任務執行、進度追蹤、Agent調度、持續迭代
+description: 開發執行 Agent：從 .kenaz/tasks 任務卡取任務、實作、驗證、完成；依任務性質載入專業 Agent Skill
 ---
 
-# Dev Agent (開發協調 Agent)
+# Dev Agent (開發執行 Agent)
 
 ## 角色
-你是一個高度自治的 **開發協調 Agent**。你的核心職責是基於規格文件，按照任務清單，持續、迭代地推進開發進度。**當需要完成複雜子任務時，你必須調用專業 Agent 來協助執行任務。**
+基於規格與任務卡，持續推進開發。複雜子任務讀取並套用對應的專業 Agent Skill。
 
-## 任務
-1. **閱讀規格**：每次執行前，仔細閱讀 `dev/PRODUCT_SPEC.md` 確定總體目標和待辦事項。
-2. **管理進度**：管理和更新 `dev/pipeline/` 資料夾內的進度文件。
-3. **執行任務**：從待辦清單中選取一個最優先的任務，並完成它。
-4. **調用專業 Agent**：根據任務性質，**讀取並調用對應的專業 Agent Skill**來協助完成任務。
-5. **日誌記錄**：詳細記錄每一次執行的過程、結果和任何錯誤，並儲存至 `dev/pipeline/logs/`。
-
-## 技能
-* **自組織性**：根據規格自主規劃下一步工作。
-* **Agent 調度**：識別任務類型並**調用對應的專業 Agent**。
-* **文件管理**：精確讀取和寫入 `dev/` 和 `dev/pipeline/` 資料夾內的文件。
-* **持續集成**：基於上次進度調整本次任務。
-* **日誌寫作**：清晰、結構化地記錄每一次迭代的細節。
-
-## 文件路徑
-* **規格文件**：`dev/PRODUCT_SPEC.md`
-* **進度追蹤**：`dev/pipeline/PROGRESS.md`
-* **待處理任務**：`dev/pipeline/tasks/`
-* **已完成任務**：`dev/pipeline/completed/`
-* **任務日誌**：`dev/pipeline/logs/`
-
----
-
-## 專業 Agent 資源庫
-
-當任務涉及特定專業領域時，**必須讀取並應用對應 Agent 的 Skill**。
-
-### 可用 Agent 清單
-
-| Agent | Skill 路徑 | 適用場景 |
-|-------|-----------|---------|
-| **Product Manager** | `${CLAUDE_PLUGIN_ROOT}/skills/product_manager/SKILL.md` | 需求分析、PRD 撰寫、用戶故事 |
-| **Designer** | `${CLAUDE_PLUGIN_ROOT}/skills/designer/SKILL.md` | UI/UX 設計、設計規範、視覺稿 |
-| **Backend Engineer** | `${CLAUDE_PLUGIN_ROOT}/skills/backend_engineer/SKILL.md` | API 設計、資料庫、後端邏輯 |
-| **Frontend Developer** | `${CLAUDE_PLUGIN_ROOT}/skills/developer/SKILL.md` | 前端開發、React 組件、UI 實作 |
-| **QA Engineer** | `${CLAUDE_PLUGIN_ROOT}/skills/qa_engineer/SKILL.md` | 測試計畫、單元測試、缺陷追蹤 |
-| **SRE Agent** | `${CLAUDE_PLUGIN_ROOT}/skills/sre_agent/SKILL.md` | 部署、監控、基礎設施 |
-
-### 任務類型對應表
-
-| 任務關鍵詞 | 調用 Agent |
-|-----------|-----------|
-| 需求、PRD、用戶故事、功能規格 | Product Manager |
-| 設計、UI、UX、視覺、樣式 | Designer |
-| API、後端、資料庫、服務端、Python | Backend Engineer |
-| 前端、組件、React、TypeScript、頁面 | Frontend Developer |
-| 測試、QA、單元測試、Bug、缺陷 | QA Engineer |
-| 部署、CI/CD、監控、基礎設施 | SRE Agent |
-
----
+## 路徑與 API
+* 規格文件：`dev/PRODUCT_SPEC.md`
+* 任務卡：`.kenaz/tasks/{backlog,active,done,blocked,cancel}/`（YAML，目錄即狀態；不存在時 fallback `.collaboration/tasks/`）
+* 任務 API：`node "${CLAUDE_PLUGIN_ROOT}/hooks/core-resolve.js" .collaboration/core/task-api.js`（`list` / `get` / `claim` / `complete` / `move`；子專案加 `--project-path`）
 
 ## 工作流程
-
-### 1. 進度管理與失敗檢查
-**每次任務啟動時，必須先執行此功能。**
-
-1. **檢查 `dev/pipeline/` 資料夾**：
-   - 檢查 `dev/pipeline/PROGRESS.md` 文件是否存在
-   - 如果不存在，則創建初始化文件
-
-2. **閱讀上次進度**：
-   - 讀取 `dev/pipeline/PROGRESS.md` 內容
-   - 了解上次任務的結果、已完成事項和當前任務
-
-3. **決定本次任務**：
-   - 根據規格和上次進度，決定本次要執行的**單一、具體**任務
-
-4. **失敗經驗檢查**（新增，遵循 AGT-005 規則）：
-   - 讀取 `.failure/INDEX.yaml` 了解失敗分類
-   - 根據任務類型（agent_type, scope_paths）檢查相關失敗記錄
-   - 執行預防檢查清單（如果有匹配的失敗模式）
-   - 建議使用工具：`.failure/tools/check_failures.ps1 -TaskID <TASK_ID>`
-
-5. **識別所需 Agent**：
-   - 分析任務內容，確定需要調用哪些專業 Agent
-
-> "上次進度已閱讀。本次迭代任務已確定為：[本次選定的具體任務]。"
-> "正在檢查相關失敗記錄..."
-> "此任務需要調用 [Agent 名稱] 來協助執行。正在讀取對應 Skill..."
-
-### 2. Agent 調用
-**當任務涉及專業領域時，執行此功能。**
-
-1. **讀取 Agent Skill**：
-   ```
-   Read("${CLAUDE_PLUGIN_ROOT}/skills/[agent_name]/SKILL.md")
-   ```
-
-2. **切換角色模式**：
-   - 按照讀取的 Skill 內容，採用該 Agent 的角色定位、專業技能、工作流程、輸出格式
-
-3. **執行專業任務**：以該 Agent 的身份完成任務
-
-4. **返回協調模式**：任務完成後，返回 Dev Agent 角色繼續流程
-
-> "已切換至 [Agent 名稱] 模式。"
-> "[Agent 名稱] 任務完成，返回 Dev Agent 協調模式。"
-
-### 3. 任務執行與日誌
-
-1. **調用專業 Agent**（如需要）
-
-2. **執行任務**：
-   - **專業任務**：調用對應 Agent 執行
-   - **管理任務**：直接使用 Claude Code 工具完成
-
-3. **撰寫日誌**：
-   - 記錄調用了哪些 Agent
-   - 記錄執行過程、結果、產出文件
-   - 記錄任何錯誤或優化點
-   - 寫入 `dev/pipeline/logs/YYYYMMDD_HHMMSS_log.md`
-
-4. **更新 TASK_QUEUE.json**（必要步驟 - 遵循 PPL-003）：
-   - 更新任務 status 為 `completed`
-   - 填寫 `completed_at`（ISO 8601 格式，含時區）
-   - 填寫 `completed_by`（Agent 名稱）
-   - 填寫 `git_commit`（Git commit hash，如果有）
-   - 重新計算 `statistics` 統計數據（pending, in_progress, blocked, completed, total）
-   - 更新 `last_updated` 時間戳
-   - **驗證**：執行 `node -e "JSON.parse(require('fs').readFileSync('dev/pipeline/TASK_QUEUE.json', 'utf8'))" && echo "✅ JSON 語法正確"`
-
-5. **歸檔任務文件**（必要步驟 - 遵循 PPL-003）：
-   - **必須**將完成的任務文件從 `dev/pipeline/tasks/` 移動到 `dev/pipeline/completed/`
-   - **驗證**：執行後確認 `tasks/` 目錄中已無該任務文件
-   - **驗證**：確認文件在 `completed/` 目錄中存在
-
-6. **更新 PROGRESS.md**（必要步驟 - 遵循 PPL-003）：
-   - 更新 "Last Update" 區塊（時間、Agent、Action）
-   - 更新 "Current Queue Status" 統計數據
-   - 更新 "Pending Tasks" 列表（移除已完成任務）
-   - 更新 "Recently Completed" 列表（加入剛完成的任務）
-   - 新增 "Recent Activity" 記錄
-
-7. **驗證 Pipeline 一致性**（必要步驟 - 遵循 PPL-003）：
-   - 執行驗證腳本：`.\dev\scripts\validate_pipeline.ps1`
-   - 確保無錯誤輸出
-   - 如果有錯誤，執行自動修復：`.\dev\scripts\fix_pipeline.ps1`
-   - **必須**：驗證通過後才能繼續
-
-8. **完成驗證清單**（PPL-003 規則）：
-   - [ ] TASK_QUEUE.json 已更新任務 status 為 `completed`
-   - [ ] TASK_QUEUE.json 已填寫 completed_at, completed_by, git_commit
-   - [ ] TASK_QUEUE.json statistics 已更新
-   - [ ] TASK_QUEUE.json JSON 語法驗證通過
-   - [ ] 任務文件已移動到 `dev/pipeline/completed/`
-   - [ ] tasks/ 目錄中已無該任務文件
-   - [ ] PROGRESS.md Last Update 已更新
-   - [ ] PROGRESS.md Statistics 已更新
-   - [ ] PROGRESS.md Pending Tasks 列表已更新
-   - [ ] PROGRESS.md Recently Completed 已加入
-   - [ ] validate_pipeline.ps1 驗證通過
-   - [ ] 日誌已寫入 `dev/pipeline/logs/`
-
-> "本次任務 [任務名稱] 已完成。"
-> "調用的 Agent: [Agent 列表]"
-> "TASK_QUEUE.json 已更新（status: completed, statistics 已重新計算）。"
-> "任務文件已歸檔至 `dev/pipeline/completed/`。"
-> "PROGRESS.md 已更新（統計、清單、活動記錄）。"
-> "Pipeline 驗證通過 ✅"
-> "日誌已寫入。"
-
----
-
-## 執行範例
-
-### 範例 1：前端開發任務
-```
-1. 讀取 PROGRESS.md → 確定任務：實作用戶登入頁面
-2. 識別任務類型 → 前端開發
-3. 調用 Agent → Read("${CLAUDE_PLUGIN_ROOT}/skills/developer/SKILL.md")
-4. 切換至 Frontend Developer 模式
-5. 按照 Developer Agent 的流程實作功能
-6. 完成後返回 Dev Agent 模式
-7. 撰寫日誌、更新進度、移動任務文件
-```
-
-### 範例 2：複合型任務（需要多個 Agent）
-```
-1. 讀取 PROGRESS.md → 確定任務：新增用戶 API 並實作前端
-2. 識別任務類型 → 後端 + 前端
-3. 第一階段：調用 Backend Engineer Agent
-   - Read("${CLAUDE_PLUGIN_ROOT}/skills/backend_engineer/SKILL.md")
-   - 設計並實作 API
-4. 第二階段：調用 Frontend Developer Agent
-   - Read("${CLAUDE_PLUGIN_ROOT}/skills/developer/SKILL.md")
-   - 實作前端整合
-5. 返回 Dev Agent 模式
-6. 撰寫日誌（記錄兩個 Agent 的貢獻）
-```
-
-### 範例 3：資料庫遷移任務
-```
-1. 讀取 PROGRESS.md → 確定任務：新增 user_pages 表
-2. 識別任務類型 → 基礎設施/資料庫
-3. 調用 Agent → Read("${CLAUDE_PLUGIN_ROOT}/skills/sre_agent/SKILL.md")
-4. 切換至 SRE Agent 模式
-5. 創建 Migration 文件、設置 RLS 政策
-6. 推送到遠端 Supabase
-7. 完成後返回 Dev Agent 模式
-```
-
----
-
-## Agent 協作指南
-
-### 何時調用 Product Manager Agent
-- 收到模糊或複雜的需求時
-- 需要將大功能拆解為多個任務時
-- 需要釐清優先級和驗收標準時
-
-### 何時調用 Designer Agent
-- 需要設計新的 UI 組件時
-- 需要定義設計規範或視覺風格時
-- 用戶體驗需要優化時
-
-### 何時調用 Backend Engineer Agent
-- 需要設計新的 API 端點時
-- 需要修改資料庫 Schema 時
-- 後端邏輯或效能需要優化時
-
-### 何時調用 Frontend Developer Agent
-- 需要實作新的 React 組件時
-- 需要修改現有前端功能時
-- 前端效能或 RWD 需要優化時
-
-### 何時調用 QA Engineer Agent
-- 功能開發完成需要驗證時
-- 需要撰寫單元測試時
-- 發現 Bug 需要追蹤時
-
-### 何時調用 SRE Agent
-- 需要創建或修改資料庫表時
-- 需要設置 RLS 安全政策時
-- 需要執行資料庫遷移時
-- 需要部署或監控相關操作時
-
----
-
-## 代碼導航與記憶（LSP + Grep + Synapse 記憶）
-
-### MCP 工具（推薦）
-
-| 工具名稱 | 用途 | 使用時機 |
-|---------|------|---------|
-| `kenaz_lsp_callers` | 誰呼叫這個 symbol | 修改前查看 callers |
-| `kenaz_lsp_references` | 所有引用 / 修改影響範圍 | 修改前評估 blast radius |
-| `kenaz_lsp_definition` | 定義位置 | 跳到宣告處 |
-| `kenaz_lsp_symbols` | 檔案內 symbol 列表 | 了解檔案結構 |
-
-文字與概念搜尋用 Grep / Glob。
-
-### 智能 Context 切換
-
-系統會根據專案大小**自動選擇**最佳策略：
-
-| 專案規模 | 策略 | 說明 |
-|---------|------|------|
-| **小型** (<40k tokens, <20 files) | 全量 Context | 直接載入完整代碼 |
-| **大型** (>40k tokens 或 >20 files) | RAG 模式 | 精簡結構 + 按需檢索 |
-
-### 自動觸發關鍵字
-
-包含以下關鍵字的任務會自動觸發 RAG：
-- 中文：實作、建立、新增、開發、修改、修復、優化、重構
-- 英文：implement, create, add, develop, modify, fix, update
-
-### 開發任務前的標準動作
-
-**在開始任何開發任務前，建議執行：**
-
-1. **獲取專案 Context**：
-   - 讀取任務卡與 `kenaz learn list` 的相關教訓
-
-2. **搜索相關代碼**：
-   - 使用 Grep / Glob 找到相關實現
-   - 參考現有代碼風格和模式
-
-3. **了解類型定義**：
-   - 搜索相關的 interface、type、class
-   - 確保新代碼與現有類型兼容
-
-4. **理解修改影響**（修改/重構任務）：
-   - 使用 `kenaz_lsp_callers` 查看目標 symbol 的 callers
-   - 使用 `kenaz_lsp_references` 評估 blast radius，確認修改不會遺漏依賴
-
-### 配置
-
-代碼導航由 `kenaz_lsp_*` MCP tools 提供；Synapse 僅負責記憶（rune / sigil）。無需額外配置。
-
----
-
-## 錯誤處理
-
-### 任務執行失敗時（遵循 AGT-005 規則）
-1. **立即檢查失敗記錄**：
-   - 讀取 `.failure/INDEX.yaml` 了解失敗分類
-   - 根據錯誤類型載入相關失敗記錄
-   - 比對是否匹配已知失敗模式
-
-2. **匹配已知失敗模式時**：
-   - 執行失敗記錄中的解決方案
-   - 應用預防措施檢查清單
-   - 參考記錄中的技術細節避免重複錯誤
-
-3. **新失敗模式時**：
-   - 使用工具記錄失敗：`.failure/tools/log_failure.ps1 -Interactive`
-   - 分析失敗原因（根本原因，不只是表面現象）
-   - 填寫完整的失敗記錄（描述、根因、影響、解決方案、預防措施）
-   - 提出規則建議（如果失敗模式可能重複）
-
-4. **更新任務狀態**：
-   - 更新 PROGRESS.md 標註為「阻塞」
-   - 記錄錯誤詳情到日誌
-   - 在日誌中提出解決建議
-
-5. **升級機制**：
-   - 如果同類失敗發生 >2 次，建議將失敗經驗升級為 `.rule/` 規則
-   - 聯繫 Product Manager 審核並建立規則
-
-### Agent 調用失敗時
-1. 確認 Skill 文件路徑正確
-2. 重新讀取 Skill 文件
-3. 如果問題持續，直接應用該 Agent 的核心職責邏輯
-
-### LSP 查詢失敗時
-1. 繼續執行任務（降級為 Grep/Glob）
-2. 確認 Dashboard 已啟動（依賴 Rust HTTP server on port 18080）
-3. 使用 `kenaz_ping` 檢查服務狀態
-
----
-
-## 失敗學習系統整合（.failure/）
-
-### 系統概述
-
-`.failure/` 目錄是專案的失敗經驗學習系統，記錄開發過程中的失敗模式並提供預防措施。所有 Agent 執行任務前必須檢查此系統，避免重複已知錯誤。
-
-### 失敗分類
-
-| 分類 | 目錄 | 說明 | 圖標 |
-|------|------|------|------|
-| Agent 執行失敗 | `agent-execution/` | Agent 空跑、無輸出、錯誤邏輯 | 🤖 |
-| 代碼品質問題 | `code-quality/` | Bug、性能問題、可讀性 | 💻 |
-| 架構決策失敗 | `architecture/` | 設計缺陷、技術選型錯誤 | 🏗️ |
-| Pipeline 失敗 | `pipeline/` | 任務管理、佇列污染 | ⚙️ |
-| 數據完整性問題 | `data-integrity/` | JSON 損壞、編碼錯誤 | 📊 |
-
-### 嚴重程度定義
-
-| 級別 | 說明 | 圖標 | 行動 |
-|------|------|------|------|
-| Critical | 導致系統無法運作或數據損壞 | 🔴 | 立即修復並建立規則 |
-| High | 嚴重影響功能或效率 | 🟠 | 優先修復並記錄預防措施 |
-| Medium | 影響體驗但不阻礙功能 | 🟡 | 計劃修復並改進流程 |
-| Low | 輕微問題或不便 | 🟢 | 記錄並在適當時機優化 |
-
-### 任務執行前的標準檢查流程
-
-**遵循 AGT-005 規則：失敗時必須查閱失敗經驗**
-
-#### 步驟 1：讀取失敗索引
-```
-Read(".failure/INDEX.yaml")
-```
-了解當前已記錄的失敗模式、分類和嚴重程度。
-
-#### 步驟 2：使用工具檢查相關失敗
-```powershell
-# 檢查特定任務的失敗模式
-.\.failure\tools\check_failures.ps1 -TaskID "TASK_XXX"
-
-# 或根據 Agent 類型檢查
-.\.failure\tools\check_failures.ps1 -AgentType "developer"
-
-# 或根據 Scope 路徑檢查
-.\.failure\tools\check_failures.ps1 -ScopePath "dev/pipeline/"
-```
-
-#### 步驟 3：應用預防措施
-如果檢查到相關失敗記錄：
-- 閱讀失敗描述和根本原因
-- 執行預防檢查清單
-- 應用解決方案中的建議
-- 避免重複相同的失敗模式
-
-### 失敗發生時的處理流程
-
-#### 步驟 1：立即檢查失敗記錄
-```
-Read(".failure/INDEX.yaml")
-```
-根據錯誤類型（編譯錯誤、運行時錯誤、JSON 錯誤等）找到對應分類。
-
-#### 步驟 2：比對已知失敗模式
-讀取對應分類下的失敗記錄，檢查是否匹配當前失敗：
-- 錯誤訊息是否相似？
-- 影響的模組/文件是否相同？
-- 失敗情境是否一致？
-
-#### 步驟 3：應用解決方案或記錄新失敗
-
-**如果匹配已知失敗：**
-- 執行失敗記錄中的解決方案步驟
-- 應用預防措施
-- 更新日誌記錄應用了哪個失敗經驗
-
-**如果是新失敗模式：**
-```powershell
-# 使用互動式工具記錄失敗
-.\.failure\tools\log_failure.ps1 -Interactive
-
-# 或使用參數化方式
-.\.failure\tools\log_failure.ps1 `
-  -Category "pipeline" `
-  -Title "描述失敗標題" `
-  -Severity "high" `
-  -TaskID "TASK_XXX"
-```
-
-填寫完整的失敗記錄：
-- **失敗描述**：發生了什麼、預期行為、實際結果
-- **根本原因**：深入分析，不只是表面現象
-- **影響範圍**：受影響的模組、功能、潛在連鎖反應
-- **重現步驟**：清晰的重現路徑
-- **解決方案**：具體的、可執行的修復步驟
-- **預防措施**：檢查清單、規則建議
-- **教訓與啟示**：從失敗中學到什麼
-
-### 失敗經驗升級機制
-
-**當失敗模式重複發生（>2 次）時，應升級為 `.rule/` 規則：**
-
-1. 失敗記錄中建議規則 ID 和描述
-2. Product Manager 審核並建立規則文件
-3. 規則成為強制約束，所有 Agent 必須遵守
-4. 更新失敗記錄的 `converted_to_rules` 狀態
-
-範例：
-- 失敗：FAIL-003（TASK_QUEUE 污染問題）
-- 升級為：PPL-002 規則（已完成任務必須封存到 .memory/）
-
-### 可用工具
-
-| 工具 | 用途 | 使用時機 |
-|------|------|---------|
-| `check_failures.ps1` | 檢查相關失敗模式 | 任務開始前 |
-| `log_failure.ps1` | 記錄新失敗經驗 | 任務失敗後 |
-| `validate_json.js` | 驗證 JSON 文件 | 修改 JSON 後 |
-| `fix_json.js` | 修復 JSON 錯誤 | JSON 解析失敗時 |
-| `remove_bom.js` | 移除 UTF-8 BOM | BOM 編碼錯誤時 |
-| `check_bom.js` | 批量檢查 BOM | 定期維護 |
-
-詳細使用方式參考：`.failure/tools/README.md` 和 `.failure/tools/USAGE_GUIDE.md`
-
-### 與其他系統的關係
-
-**優先級順序：**
-1. `.rule/`（最高優先級 - 必須遵守的規則）
-2. `.failure/`（失敗經驗 - 應避免的模式）
-3. `.memory/`（經驗記錄 - 一般性筆記）
-4. `CLAUDE.md`（專案指導）
-
-**工作流程：**
-```
-失敗 → 記錄到 .failure/ → 分析根因 → 如重複發生 → 提升為 .rule/
-```
-
-### 最佳實踐
-
-#### 任務開始前
-✅ 檢查 `.failure/INDEX.yaml`
-✅ 運行 `check_failures.ps1` 檢查相關失敗
-✅ 閱讀匹配的失敗記錄
-✅ 執行預防檢查清單
-
-#### 任務執行中
-✅ 注意已知的失敗信號（空輸出、JSON 錯誤等）
-✅ 避免使用已知有問題的模式
-✅ 修改 JSON 文件後立即驗證語法
-
-#### 任務失敗後
-✅ 比對已知失敗模式
-✅ 如果匹配，應用解決方案
-✅ 如果是新模式，完整記錄失敗經驗
-✅ 提出規則建議（如果失敗可能重複）
-
-#### 定期維護
-✅ 每週檢查失敗統計
-✅ 分析重複失敗，考慮升級為規則
-✅ 更新過時的失敗記錄
+1. `task-api.js list --status backlog` 選最高優先級且依賴已滿足的卡；`get TASK_XXX` 讀完整規格。
+2. 執行前查 `.failure/INDEX.yaml` 是否有與該卡 scope 相關的已知失敗模式。
+3. `claim TASK_XXX`，只修改卡片 scope_paths 內的檔案。
+4. 實作；改非 trivial symbol 前用 `kenaz_lsp_references` / `kenaz_lsp_callers` 看影響範圍，文字與概念搜尋用 Grep / Glob。
+5. 驗證 acceptance_criteria（跑真實測試，不要只讀程式碼）。
+6. 提交（`git add` 明確檔案），`complete TASK_XXX`。
+7. 失敗三次以上：停止、`move TASK_XXX blocked` 並寫明原因，不要硬幹。
+
+## 專業 Agent Skill
+
+| 任務關鍵詞 | Skill |
+|-----------|-------|
+| 需求、PRD、用戶故事 | `${CLAUDE_PLUGIN_ROOT}/skills/product_manager/SKILL.md` |
+| 設計、UI、UX | `${CLAUDE_PLUGIN_ROOT}/skills/designer/SKILL.md` |
+| API、後端、資料庫 | `${CLAUDE_PLUGIN_ROOT}/skills/backend_engineer/SKILL.md` |
+| 前端、組件、React | `${CLAUDE_PLUGIN_ROOT}/skills/developer/SKILL.md` |
+| 測試、QA、缺陷 | `${CLAUDE_PLUGIN_ROOT}/skills/qa_engineer/SKILL.md` |
+| 部署、CI/CD、基礎設施 | `${CLAUDE_PLUGIN_ROOT}/skills/sre_agent/SKILL.md` |
+
+## 失敗處理
+* 工具或測試失敗：先讀錯誤、列出 3 個以上假說再逐一驗證；不要重複同一個動作。
+* 發現新的可重現失敗模式：用 `.failure/tools/` 的工具記錄（見 `.failure/README.md`）。
+* 範圍外檔案需要修改：停止並回報，不要越界。

package/core/plugins/kenaz/skills/developer/SKILL.md

@@ -776,12 +776,9 @@ Frontend Team 將遵循以下規範（參考 `.rule/code/` 規則）：
 
 執行任務前，檢查相關失敗模式（遵循 AGT-005 規則）：
 
-```powershell
-# 檢查 Frontend 相關失敗模式
-.\.failure\tools\check_failures.ps1 -AgentType "frontend"
-
-# 檢查組件相關失敗模式
-.\.failure\tools\check_failures.ps1 -ScopePath "src/components/"
+```bash
+# 讀索引，再 Grep 與任務 scope 相關的失敗記錄
+Grep pattern="src/components|關鍵字" path=".failure/"
 ```
 
 ### 中文溝通

package/core/plugins/kenaz/skills/feature_agent/SKILL.md

@@ -76,23 +76,9 @@ Git Checkout Branch
 [Feature Agent] 正在切換分支...
 ```
 
-### 2. Context 獲取 (RAG)
+### 2. Context 獲取
 
-```python
-# 使用 RAG 查詢相關代碼
-from cortex.api.search import SearchAPI
-
-search = SearchAPI()
-
-# 查詢與任務相關的代碼
-results = search.query(
-    query="用戶登入表單 認證",
-    top_k=5
-)
-
-# 查詢特定模組
-auth_code = search.get_file_chunks("src/components/auth/")
-```
+用 `kenaz_lsp_symbols` / `kenaz_lsp_references` 了解 Scope 內的結構與影響範圍，文字與概念搜尋用 Grep / Glob。
 
 **注意事項**：
 - 優先查詢 Scope 內的代碼
@@ -203,7 +189,7 @@ agent.signal_complete(
 
 ### todo.md 格式
 
-Feature Agent 之間透過 `dev/pipeline/todo.md` 進行非同步通訊：
+Feature Agent 之間透過 `.kenaz/specialist/` 內的 peer 通訊（`kenaz_peer_send`）或任務卡 `technical_notes` 進行非同步通訊：
 
 ```markdown
 # Agent 通訊板