recursive-decomposition
作者 massimodeluisarecursive-decomposition 是一種適用於大型、多檔案或多跳任務的工作流程自動化技能。它會把工作拆成更小的部分，分別處理後再合併結果，讓程式碼庫審查、文件彙整與結構化擷取更可靠；尤其在單一 prompt 會太淺、太脆弱時特別有用。
這項技能評分為 74/100，代表它是可用但仍有些限制的目錄項目。它為大型、多檔案或長上下文任務提供清楚的觸發條件與實際的拆解流程，但使用者應預期會比較依賴內附參考資料與範例，而不是一套非常完整、開箱即用的安裝體驗。
- 對大型文件與多檔案工作的明確觸發條件，讓 agent 很容易辨識並啟用這項技能。
- 內容量充足，包含 13 個 H2、7 個 H3、code fences 與具體參考資料，提供可重用的拆解指引，而不是只有占位內容。
- 用例與判斷規則清楚說明何時採用 recursive 或 direct processing，有助於 agent 在程式碼庫分析與文件彙整任務上發揮更好效果。
- 沒有安裝指令，也沒有支援腳本，因此採用時更仰賴閱讀 `SKILL.md` 與參考資料，而不是執行一個已封裝好的工作流程。
- 內容中可見占位標記，表示某些章節可能仍未完成，或在處理邊緣情境前還需要進一步修訂。
recursive-decomposition 技能概覽
recursive-decomposition 技能可協助你處理大型、多檔案或多跳步驟的任務，把工作拆成較小部分，分別處理後再整合結果。它特別適合 recursive-decomposition for Workflow Automation、跨整個 codebase 的審查，以及多文件擷取；當單一 prompt 會太淺或太脆弱時，這個技能最能發揮作用。
這個技能適合做什麼
當工作重點不是「回答一個問題」，而是「可靠地分析大量素材」時，就該使用 recursive-decomposition 技能。常見情境包括：掃描大量檔案、比對整個 codebase 的模式、從多份文件中擷取結構化事實，或是把分散來源整理成一份統整報告。
它和一般 prompt 有什麼不同
一般 prompt 會要求模型一次把所有內容都處理完。這個技能則會引導你採用逐步揭露的方式：先縮小搜尋範圍，再遞迴深入相關部分，最後進行彙整。當 context 衰退、漏看檔案，或整合結果不一致會影響輸出品質時，這就是它最大的優勢。
最適合的使用情境
當你面對 10+ 個檔案、50k+ tokens，或需要系統性覆蓋而不是快速摘要的任務時，recursive-decomposition 技能會非常合適。若是範圍小、很局部的問題，直接處理通常更便宜也更快。
如何使用 recursive-decomposition 技能
安裝並啟用
執行 recursive-decomposition install 時，先把這個 skill 加進你的 Claude Code 或任何已啟用 skills 的工作流程；只有在任務明顯超出單次上下文負荷時再呼叫它。該 repo 的 SKILL.md 會指向 references/ 裡的支援資料，實務上的判斷規則就寫在那裡。
從正確的輸入開始
先給 skill 明確的目標、範圍邊界與輸出格式。好的輸入像是：「分析 src/api、src/services、src/utils 的錯誤處理方式；回傳一份包含模式、缺口與建議的表格。」不好的輸入則像是：「幫我 review 這個 repo。」
先讀這些檔案
在使用 recursive-decomposition 時，先從 SKILL.md 看起，再檢視 references/cost-analysis.md、references/codebase-analysis.md、references/document-aggregation.md 與 references/rlm-strategies.md。這些檔案會說明何時該遞迴、如何切分工作，以及如何在不失去結構的情況下彙整結果。
能提升結果品質的工作流程
建議依序做：定義範圍、找出候選檔案或文件、積極過濾、批次處理剩餘項目、平行執行子任務，最後把發現整合成同一套 schema。recursive-decomposition 指南最有效的使用方式，是明確指出哪些內容應排除、什麼算證據，以及最終輸出應如何組織。
recursive-decomposition 技能 FAQ
什麼時候該用 recursive-decomposition？
當任務橫跨許多檔案、許多文件，或需要很大的 token 預算，而且完整性比速度更重要時，就該用它。若工作範圍局部、狹窄，或已經界定得很清楚，通常直接處理就夠了。
recursive-decomposition 只適用於 codebase 嗎？
不是。這種模式同樣適用於 codebase、研究筆記、PRD、長篇報告，以及其他文件集合。關鍵條件是：這項任務能從過濾、分割與彙整中受益。
主要的失敗模式是什麼？
最常見的失敗，是把 recursive-decomposition 用在定義不夠清楚的任務上。如果你沒有定義目標集合、輸出格式或驗收標準，這個技能即使遞迴得很有效率，最後仍可能產出焦點分散的結果。
這個技能適合初學者嗎？
適合，只要你能說清楚具體目標和範圍邊界。初學者通常最適合先要求一個明確交付項，例如缺口分析、清單整理或比較報告，而不是開放式探索。
如何改進 recursive-decomposition 技能
給技能更窄的搜尋框架
最好的 recursive-decomposition 用法，從一個有邊界的問題開始。不要說「review 這個 repository」，而要說「找出 src/api 和 src/services 裡所有錯誤處理模式，標出不一致之處，並依模組整理摘要」。明確的框架能減少雜訊，也讓遞迴的額外成本變得值得。
提供擷取 schema
如果你想要結構化輸出，就直接說每個項目要包含哪些欄位。例如：file、pattern、severity、evidence、recommendation。這樣能幫助 skill 保持各個平行子結果可比，而不是各自用不同方式敘述。
明確設定門檻與排除項目
repository 的決策邏輯重點看 token 數、檔案數，以及你更重視品質還是延遲。如果你知道自己的限制，就直接說出來：exclude tests、ignore archived docs，或