recursive-decomposition
作者 massimodeluisarecursive-decomposition 是一款面向大规模、多文件或多跳任务的工作流自动化技能。它会把工作拆成更小的部分，分别处理后再合并结果，从而在代码库审查、文档汇总和结构化抽取等场景中，比单次提示更可靠；尤其适合单次提示容易过浅或不稳定的任务。
这项技能评分为 74/100，说明它是一个可用但略显有限的目录条目。它为大规模、多文件或长上下文任务提供了清晰的触发条件和真实可用的分解流程，但用户应预期主要依赖随附参考和示例，而不是一种高度打磨好的开箱即用安装体验。
- 针对大文档和多文件工作的明确触发条件，让 agent 很容易识别并调用这项技能。
- 内容主体充实，包含 13 个 H2、7 个 H3、代码块和具体参考信息，提供的是可复用的分解指导，而不是占位内容。
- 关于何时使用递归处理、何时使用直接处理的示例和判断规则，有助于提升 agent 在代码库分析和文档汇总任务中的发挥空间。
- 没有安装命令，也没有配套脚本，这意味着采纳时更多要依赖阅读 `SKILL.md` 和参考资料，而不是运行一个打包好的工作流。
- 其中存在占位标记，因此在用户将其用于边缘情况前，某些部分可能仍不完整，或者需要进一步打磨。
recursive-decomposition 技能概览
recursive-decomposition 技能可以把大型、跨文件或多跳任务拆成更小的部分，分别处理后再合并结果。它特别适合 Workflow Automation、全仓库审查和多文档抽取这类场景；当单次 prompt 过于浅、或太容易出错时，这个 recursive-decomposition 技能会更有用。
这个技能适合做什么
当任务不是“回答一个问题”，而是“可靠地分析一大批材料”时，就该用 recursive-decomposition 技能。常见适用场景包括：扫描大量文件、对整个 codebase 做模式比较、从多份文档中抽取结构化事实，或者基于分散来源整理一份汇总报告。
它和普通 prompt 有什么不同
普通 prompt 往往要求模型一次性装下全部信息。而 recursive-decomposition 技能会把流程推向逐步展开：先缩小搜索范围，再递归处理相关部分，最后再综合。只要你担心上下文污染、漏文件，或者汇总结果不一致，这就是它的核心优势。
最适合的使用场景
当你面对 10+ 个文件、50k+ tokens，或者需要系统性覆盖而不是快速概览的任务时，recursive-decomposition 技能会非常合适。对于范围很小、问题很局部的任务，它反而不如直接处理来得省事、也更快。
如何使用 recursive-decomposition 技能
安装并启用它
要进行 recursive-decomposition install，先把这个 skill 加到你的 Claude Code 或支持 skills 的工作流里，然后在任务明显超出单次上下文时再调用它。仓库里的 SKILL.md 会指向 references/ 里的辅助资料，那里是实际的决策规则所在。
从正确的输入开始
给这个 skill 传入目标、范围边界和输出格式。好的输入示例是：“分析 src/api、src/services 和 src/utils 中的错误处理方式；返回一个包含模式、缺口和建议的表格。” 不好的输入示例是：“检查这个 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 用在一个定义不清的任务上。如果你没有明确目标集合、输出格式或验收标准，这个 skill 可能会很高效地递归下去，但最后还是得到一个焦点不清的结果。
这个技能适合新手吗？
适合，只要你能说清一个具体目标和范围边界。新手通常最适合先要一个明确交付物，比如 gap analysis、inventory 或 comparison，而不是开放式探索。
如何改进 recursive-decomposition 技能
给这个技能更紧的搜索框架
最好的 recursive-decomposition 用法，一开始就应该是一个有边界的问题。不要说“检查这个仓库”，而是说“找出 src/api 和 src/services 中所有错误处理模式，指出不一致之处，并按模块总结。” 更明确的框架可以减少噪音，也能让递归带来的额外开销变得值得。
提供抽取 schema
如果你想要结构化输出，就直接说明每一项应该包含什么。比如：file、pattern、severity、evidence 和 recommendation。这样可以帮助这个 skill 让并行子结果保持可比性，而不是各自用不同方式叙述。
明确阈值和排除项
仓库里的决策逻辑强调 token 数、文件数，以及质量是否比延迟更重要。如果你已经知道自己的约束，就直接说出来：exclude tests、ignore archived docs，或者