一键导入
bulk-evaluate
子任務拆分與 Context 卸載工具。將可拆分的大型任務分成 N 個子 Ticket,各由 Agent 獨立執行,結論直接寫入 Ticket 不回報主線程。Use for: 批量檔案評估, 大型審查任務拆分, 任何需要讀取大量資料但結果可落地到 Ticket 的任務
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
子任務拆分與 Context 卸載工具。將可拆分的大型任務分成 N 個子 Ticket,各由 Agent 獨立執行,結論直接寫入 Ticket 不回報主線程。Use for: 批量檔案評估, 大型審查任務拆分, 任何需要讀取大量資料但結果可落地到 Ticket 的任務
用 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 錯誤後。
認知負擔評估與審查工具。作為決策樹、代理人、Code Review 的基本參考標準。用於: (1) 任務複雜度評估, (2) 代理人升級判斷, (3) 任務拆分建議, (4) 程式碼品質審查與熱點識別
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 | bulk-evaluate |
| description | 子任務拆分與 Context 卸載工具。將可拆分的大型任務分成 N 個子 Ticket,各由 Agent 獨立執行,結論直接寫入 Ticket 不回報主線程。Use for: 批量檔案評估, 大型審查任務拆分, 任何需要讀取大量資料但結果可落地到 Ticket 的任務 |
例外情況的批次計算公式: references/context-budget-formula.md
問題:主線程的 context 有限。當一個任務需要讀取大量資料(N 個檔案、N 個模組、N 個報告),全部由主線程處理會溢出 context。
解法:把「讀取 + 分析 + 記錄」整包卸載給 Agent,主線程只負責拆分和統計。
關鍵設計:Ticket 既是任務指派,也是分析報告的載體。Agent 把結論直接寫入子 Ticket,主線程不接收完整內容 — 只看 Ticket 狀態和摘要統計。
傳統模式(主線程 context 溢出):
主線程讀取 N 個檔案 → 分析 → 產出報告 → context 爆炸
卸載模式(本 Skill):
主線程建立 N 個子 Ticket → 派發 Agent → Agent 寫入 Ticket → 主線程只看統計
| 場景 | 子任務單位 | 每個子 Ticket 的內容 |
|---|---|---|
| Agent/Skill 合規掃描 | 1 個定義檔案 | 評估結論 + 具體問題 |
| 規則一致性檢查 | 1 個規則檔案 | 衝突發現 + 建議修正 |
| 測試品質批量審查 | 1 個測試檔案/目錄 | 品質評分 + 改善建議 |
| 大型重構影響分析 | 1 個模組/目錄 | 影響範圍 + 遷移方案 |
| 多模組效能掃描 | 1 個效能熱點 | 瓶頸分析 + 優化建議 |
通用判斷:只要任務可以表述為「對 N 個獨立單位各做一次相同的分析」,就適用本 Skill。
/parallel-evaluation 的區別| 維度 | /parallel-evaluation | /bulk-evaluate |
|---|---|---|
| 並行軸 | N 個視角 x 1 組目標 | 1 個標準 x N 個單位 |
| 產出物 | 彙整報告(回到主線程) | N 個子 Ticket(不回主線程) |
| Context 影響 | 主線程接收彙整結果 | 主線程只看統計摘要 |
| 目的 | 多角度快速評估 | 批量處理 + context 卸載 |
確定每個子任務的處理單位和分析標準。
問自己:
1. 這個任務可以拆成幾個「對 X 做同一件事」的子任務?
2. 每個子任務的輸入是什麼?(一個檔案?一個模組?一個報告?)
3. 每個子任務的產出寫在哪?(Ticket 的哪個欄位?)
4. 分析標準是什麼?(參考文件?檢查清單?評估維度?)
/ticket create → 父 Ticket(匯總任務,type: ANA)
|-- /ticket create --parent → 子 Ticket 1(單位 A 的分析)
|-- /ticket create --parent → 子 Ticket 2(單位 B 的分析)
└── ...
每個子 Ticket 的驗收條件統一為:
預設: 1 個子任務 = 1 個 Agent
59 個評估目標 → 59 個獨立 Agent
每個 Agent 只負責 1 個目標
為什麼不批次處理:
| 維度 | 批次處理 | 1:1 派發 |
|---|---|---|
| 認知負擔 | Agent 需同時理解多個目標 | 只專注一個目標 |
| 判斷品質 | 目標間資訊互相干擾 | 零干擾,判斷最精準 |
| 失敗隔離 | 一批失敗影響多個子任務 | 單點失敗不擴散 |
這就是 context 卸載的核心目的:讓每個 process 的任務目標清晰明確,避免額外資訊干擾判斷。
例外:僅當平台限制無法派發足夠 Agent 時,才參考 references/context-budget-formula.md 計算合理批次大小。
每個 Agent 的 prompt 包含:
Agent 不需要知道:其他目標的存在、總共有幾個子任務、其他 Agent 的結論。
Agent 類型選擇:
| 需要寫入 Ticket | 推薦 Agent |
|---|---|
| 是 | general-purpose |
| 否(只讀分析) | Explore / Plan |
所有 Agent 完成後,主線程只做統計(不讀取子 Ticket 全文):
## 批量評估結果
**父 Ticket**: {ID} **子任務總數**: {N} **完成**: {M}/{N}
| 結論類別 | 數量 | 佔比 |
|---------|------|------|
| [類別 A] | X | X% |
| [類別 B] | X | X% |
### 需關注的子任務
| # | 子 Ticket | 結論 | 簡要 |
|---|----------|------|------|
更新父 Ticket 狀態,流程結束。
Step 1: 子任務單位 = 每個 agent/skill 定義檔案
分析標準 = design-guide (~25KB)
Step 2: 父 Ticket + 59 個子 Ticket
Step 3: 預設 1:1 → 59 個獨立 Agent
Step 4: 並行派發 59 個 general-purpose Agent,各處理 1 個子 Ticket
每個 Agent 只讀取: design-guide + 自己負責的 1 個定義檔案
Step 5: 統計 59 個子 Ticket 結論 → 更新父 Ticket
主線程 context 消耗: 只有 Step 2(建 Ticket)和 Step 5(統計),不讀取 59 個定義檔案。 每個 Agent context 消耗: ~25KB 標準 + ~17KB 目標 = ~42KB,遠低於 context 上限。
Last Updated: 2026-03-02 Version: 1.0.0