/update — 更新知識庫

將本次 session 的工作沉澱為文件與可復用知識。依序執行文件更新、品質審查、模式提取三個階段。

ECC 資源前置確認： 確認 doc-updater agent 和 learn-eval skill 的可用狀態。若已被 defer，提示使用者先 restore 或調整流程。

與 /pr 的分工：/update 負責知識沉澱，/pr 負責 git 輸出。需要時可組合使用：先 /update 再 /pr。

Step 1: doc-updater — 更新文件

使用 doc-updater agent 掃描本次 session 的變更，更新相關文件。

Agent(subagent_type="everything-claude-code:doc-updater")

掃描範圍：

1. 執行 git diff --name-only HEAD 取得本次變更的檔案清單
2. 若無未 commit 變更，使用 git diff --name-only HEAD~3..HEAD 取得近期 commit 涉及的檔案
3. 若仍無任何變更，使用 AskUserQuestion 詢問：
   • 指定檔案 — 手動指定要檢查的文件
   • 全面掃描 — 掃描所有文件是否有過時內容
   • 只做 learn-eval — 跳過 Step 1-2，直接進入 Step 3 提取 patterns
   • 結束 — 結束 /update 流程
4. 根據變更內容更新：
   • docs/ 目錄下的相關文件
   • docs/CODEMAPS/ 目錄下的架構圖
   • README.md（如果功能或用法有變動）
   • 其他受影響的文件檔案

HITL 確認（必做）： 更新任何文件前，先列出「計畫更新的檔案清單」並使用 AskUserQuestion 請使用者確認：

即將更新以下文件，請確認是否正確：
1. path/to/file1.md — 原因：xxx
2. path/to/file2.md — 原因：xxx

[確認繼續] / [調整清單] / [跳過]

文件庫 / 知識庫 歧義處理： 若上下文提到「文件庫」或「知識庫」，必須先釐清指的是哪個目錄，不得自行假設：

• 可能是 docs/、research/、README.md（專案文件）
• 可能是 ~/.claude/projects/.../memory/（Claude 記憶庫）
• 可能是 ~/.claude/skills/（技能庫）
• 若無法從上下文判斷，使用 AskUserQuestion 確認後再繼續

交接資訊： 記錄更新了哪些文件檔案、變更摘要，作為下一步 code-reviewer 的輸入。

Step 2: code-reviewer — 交叉比對 + 審查文件品質

使用 code-reviewer agent 審查 Step 1 更新的文件，並交叉比對變更是否完整正確。

Agent(subagent_type="everything-claude-code:code-reviewer")

審查重點：

• 文件內容是否準確反映程式碼變更
• 是否有過時或不一致的描述
• 格式和結構是否符合專案慣例
• 是否有遺漏的重要資訊

交叉比對（Cross-check）：

1. 對照 git diff 的實際變更，逐一確認每份更新的文件是否涵蓋所有重要變更
2. 確認沒有「應該更新但漏掉的文件」
3. 確認沒有「不應該更新但錯誤修改的文件」
4. 若發現遺漏或錯誤，標示在輸出報告中

輸出格式：

Severity	項目	說明
CRITICAL	內容錯誤	文件描述與實際程式碼行為不符
HIGH	重要遺漏	缺少關鍵功能或 API 的說明
MEDIUM	格式問題	結構不一致、用語不統一

如果有 CRITICAL 或 HIGH 問題，使用 AskUserQuestion 詢問使用者：

• 修正後繼續：先修正問題，再進入 Step 3
• 跳過，直接繼續：忽略問題，繼續執行 learn-eval

Step 3: learn-eval — 提取可復用模式

使用 learn-eval 從本次 session 提取可復用的 patterns，評估品質後寫入知識庫。

Skill(skill="everything-claude-code:learn-eval")

提取範圍：

• 錯誤解決模式（debugging patterns）
• 偵錯技巧（troubleshooting insights）
• 架構決策（architectural decisions）
• 專案特定模式（project-specific patterns）
• 工具使用技巧（tool usage patterns）
• 業界標準應用（industry standard adoptions）
• 標準化方案選型（standardized solution selections）

品質評估： learn-eval 會自動進行 5 維度評分（specificity、actionability、scope fit、non-redundancy、coverage），至少達 3 分才會保存。

Step 4: 知識庫交叉比對（HITL 確認）

learn-eval 完成後，執行最終交叉比對，確認所有知識庫都已正確更新。

盤點本次 session 涉及的知識庫位置：

知識庫	路徑	說明
Claude 記憶庫	~/.claude/projects/<project-hash>/memory/MEMORY.md	專案級記憶
全域技能庫	~/.claude/skills/learned/	全域可復用 patterns
全域記憶	~/.claude/MEMORY.md	跨專案記憶（如有）
專案文件	docs/、research/、README.md	專案說明文件

交叉比對步驟：

1. 讀取上述各知識庫的實際內容
2. 對照本次 session 的工作內容，逐一確認：
   • 有做但未記錄的決策或模式
   • 記錄的內容是否與實際一致（無錯誤描述）
   • 本次引用的業界標準或學術依據是否已記錄到適當的知識庫
   • 是否有跨知識庫的不一致（例如 MEMORY.md 與 learned skill 矛盾）
3. 若發現問題，列出具體差異

HITL 確認： 比對完成後，用 AskUserQuestion 呈現結果，請使用者確認後才結束：

知識庫交叉比對結果：
✅ MEMORY.md — 已正確記錄 xxx
✅ learned/yyy.md — 內容與實作一致
⚠️ MEMORY.md 第 12 行描述與實際行為不符，建議修正：...

[確認無誤，結束] / [修正後結束]

Step 5: 總結報告

所有步驟完成後，輸出最終報告：

## /update 執行結果

### 文件更新
- 列出所有更新的文件檔案及變更摘要

### 品質審查
- 列出 code-reviewer 的審查結果
- 標示已修正 / 未修正的項目

### 知識提取
- 列出 learn-eval 提取的 patterns
- 標示保存位置（全域 / 專案級）

### 知識庫交叉比對
- 列出比對結果（✅ 正確 / ⚠️ 差異 / ❌ 錯誤）
- 標示已修正 / 待修正的項目

### 建議下一步
- 如果有未修正的問題，建議處理方式
- 如果適合開 PR，建議執行 `/pr`

Step 6: Pipeline 串接（選擇性）

檢查 $ARGUMENTS 是否包含其他 skill 名稱（如 /pr）。如果有，在 /update 完成後自動觸發。

串接觸發

如果 $ARGUMENTS 包含 "/pr"：
  → 使用 Skill tool 觸發 /pr（傳入 $ARGUMENTS 中 /pr 後面的參數）

如果 $ARGUMENTS 包含其他 /<skill-name>：
  → 使用 Skill tool 觸發對應 skill

資源去重

串接時，/update 已完成的工作會透過環境標記傳遞給下游 skill，避免重複執行：

串接 /pr 時的去重規則：

/pr 步驟	正常執行	從 /update 串接	原因
Step 1a: Git 分析	完整執行	完整執行	目的不同：/update 只需檔案清單，/pr 需要完整 diff + commit history 寫 description
Step 1b: 對話脈絡分析	完整執行	完整執行	/update 不做此步驟
Step 2: Quick Review	完整執行	跳過	/update Step 2 已用 code-reviewer agent 做過更深度審查
Step 3-6	完整執行	完整執行	無重疊

實作方式： 觸發 /pr 時，在 prompt 前加上以下指示：

[PIPELINE: from /update]
以下步驟已由 /update 完成，請跳過：
- Step 2 (Quick Review) — 已由 code-reviewer agent 完成，無 CRITICAL/HIGH 問題
其餘步驟正常執行。

用法範例

/update /pr        # 先更新知識庫，再自動 commit + push + 建立/更新 PR
/update /pr 7238   # 先更新知識庫，再更新 PR #7238

注意： 只在 /update 所有步驟（包含使用者確認）完成後才觸發下一個 skill，不會中途跳轉。