菜单
認知負擔評估與審查工具。作為決策樹、代理人、Code Review 的基本參考標準。用於: (1) 任務複雜度評估, (2) 代理人升級判斷, (3) 任務拆分建議, (4) 程式碼品質審查與熱點識別
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Composes atomic, intent-revealing, grep-friendly writing (Zettelkasten) for code comments, docs, logs, prompts, schema/ticket fields, and long-form technical articles. Use when cognitive load and token cost matter. Triggers: 寫註解, 寫文件, 寫日誌, 寫 prompt, 寫文章, 技術文章, post-mortem, 架構決策, 除錯復盤, 欄位設計, atomic, reusable.
Agent Teams 協作派發指南。Use when: (1) Agent A 的發現會改變 Agent B 正在進行的工作, (2) 用戶要求使用 team/swarm, (3) 多代理人需即時協商共用介面或 API 契約。涵蓋 team 建立、Ticket-Task 橋接、teammate 入職、生命週期管理。
Branch Worktree Guardian - Git 分支和 Worktree 管理工具。Use for: (1) 新開發需求時建立隔離分支, (2) 使用 worktree 機制避免分支衝突, (3) 驗證當前工作分支正確性, (4) 預防在錯誤分支上開發
broken-link 偵測工具。掃描 .claude/ 目錄所有 Markdown 文件中的路徑引用，偵測失效連結。Use for: (1) 一次性掃描所有 broken links, (2) 搭配 /loop 定期監控, (3) 修改規則/方法論/代理人文件後驗證路徑完整性。Use when: user runs /broken-link-check, 或搭配 /loop 定期執行, 或發現 broken link 錯誤後。
子任務拆分與 Context 卸載工具。將可拆分的大型任務分成 N 個子 Ticket，各由 Agent 獨立執行，結論直接寫入 Ticket 不回報主線程。Use for: 批量檔案評估, 大型審查任務拆分, 任何需要讀取大量資料但結果可落地到 Ticket 的任務
Extracts reusable patterns from Claude Code sessions and captures knowledge as atomic memory units, then evaluates whether each memory should be upgraded to framework-shared rules, methodologies, or error-patterns. Use when session ends (Stop hook), when recording technical decisions, implementation insights, or lessons learned. Handles automatic pattern detection, structured memory capture with interconnected knowledge links, and post-write upgrade decision flow to prevent cross-project principles being trapped in single-project memory.
| name | cognitive-load-assessment |
| description | 認知負擔評估與審查工具。作為決策樹、代理人、Code Review 的基本參考標準。用於: (1) 任務複雜度評估, (2) 代理人升級判斷, (3) 任務拆分建議, (4) 程式碼品質審查與熱點識別 |
所有程式碼設計原則的終極目標：降低閱讀者的認知負擔
認知負擔是指閱讀者在理解程式碼時需要同時記住的資訊量。當認知負擔超過人類工作記憶的容量（約 7 個項目），理解和維護程式碼就會變得困難。
| 指標 | 低複雜度 | 中複雜度 | 高複雜度（需拆分） |
|---|---|---|---|
| 變數狀態數 | 1-3 | 4-5 | > 5 |
| 修改檔案數 | 1-3 | 4-5 | > 5 |
| 架構層級數 | 1 | 2 | > 2 |
| 依賴模組數 | 0-1 | 2-3 | > 3 |
| 呼叫追蹤層 | 1-2 | 3 | > 3 |
| 指標 | 閾值 | 行動 |
|---|---|---|
| 需追蹤概念數 | > 7 | 升級到 PM |
| 無法 5 分鐘理解 | 是 | 升級到 PM |
| 跨 2+ 架構層 | 是 | 請求拆分或協作 |
| 條件 | 可並行 | 需序列 |
|---|---|---|
| 架構層級 | 同一層 | 跨層 |
| 邏輯依賴 | 無 | 有 |
| 操作類型 | 重命名/格式化 | 設計變更 |
每個變數都是閱讀者需要「記住」的項目：
| 情況 | 認知負擔 | 建議 |
|---|---|---|
| 變數數 <= 3 | 低 | 維持 |
| 變數數 4-5 | 中 | 考慮重構 |
| 變數數 > 5 | 高 | 必須拆分 |
追蹤呼叫鏈需要「堆疊」記憶：
| 層級 | 認知負擔 | 建議 |
|---|---|---|
| 1-2 層 | 低 | 維持 |
| 3 層 | 中 | 考慮扁平化 |
| > 3 層 | 高 | 必須重構 |
不佳的命名增加「翻譯」負擔：
| 問題 | 範例 | 解決 |
|---|---|---|
| 縮寫不明 | btn, mgr, idx | button, manager, index |
| 含義模糊 | data, info, value | 具體化：userData, bookInfo |
| 型別前綴 | strName, intCount | 直接用 name, count |
每個分支都是需要考慮的「路徑」：
| 分支數 | 認知負擔 | 建議 |
|---|---|---|
| 1-2 | 低 | 維持 |
| 3-4 | 中 | 考慮策略模式 |
| > 4 | 高 | 必須重構 |
一個函式只做一件事，讓讀者只需理解一個概念
檢查問題：「這個函式做了幾件事？」
名稱本身就是文件，讓讀者不需要額外資訊
檢查問題：「不看實作，能從名稱理解功能嗎？」
函式的行為應該可預測，讓讀者不需要追蹤隱藏狀態
檢查問題：「這個函式有沒有修改輸入以外的東西？」
減少巢狀，讓讀者不需要追蹤深層上下文
檢查問題：「最深的巢狀層級是多少？（應 <= 3）」
相關的資訊應該放在一起，讓讀者不需要跳轉尋找
檢查問題：「理解這段程式碼需要跳到幾個地方？」
Code Review 的目標不只是找出錯誤，更重要的是確保程式碼對未來的閱讀者友善。
| 維度 | 檢查問題 |
|---|---|
| 變數狀態追蹤 | 這段程式碼需要閱讀者同時記住幾個變數的狀態？ |
| 呼叫層級追蹤 | 理解這段程式碼需要追蹤幾層呼叫？ |
| 命名品質 | 不看實作，能從名稱理解意圖嗎？ |
| 條件分支 | 需要考慮幾條執行路徑？ |
| 函式長度 | 這個函式做了幾件事？ |
| 參數數量 | 呼叫者需要記住幾個參數的順序和意義？ |
| 熱點類型 | 識別方法 | 影響 |
|---|---|---|
| 長函式 | > 20 行 | 難以一次理解 |
| 深巢狀 | > 3 層縮排 | 上下文難追蹤 |
| 多參數 | > 3 個參數 | 呼叫時容易出錯 |
| 副作用 | 修改外部狀態 | 行為不可預測 |
| 隱藏依賴 | 內部 new 物件 | 難以測試和理解 |
# 審查單一檔案
/cognitive-load-assessment review {檔案路徑}
# 快速掃描目錄
/cognitive-load-assessment scan {目錄}
詳細報告模板：references/review-report-template.md
常見問題模式：references/common-review-patterns.md
| 方法論 | 認知負擔視角 |
|---|---|
| DRY | 減少重複 = 減少需要記憶的版本 |
| SOLID | 每個原則都在降低特定類型的認知負擔 |
| Clean Code | 可讀性 = 低認知負擔 |
| 自然語言程式設計 | 讓程式碼像閱讀文章一樣自然 |
/cognitive-load-assessment assess-task "{任務描述}"
/cognitive-load-assessment assess-code {檔案路徑}
Last Updated: 2026-03-02 Version: 2.0.0 - 合併 cognitive-load-review，新增 Code Review 模式和 references/