recursive-decomposition
by massimodeluisarecursive-decomposition is a workflow automation skill for large, multi-file, or multi-hop tasks. It splits work into smaller parts, processes them independently, and merges results for more reliable codebase reviews, document aggregation, and structured extraction when a single prompt would be too shallow or fragile.
This skill scores 74/100, which means it is a valid but somewhat limited listing for directory users. It gives agents a clear trigger and a real decomposition workflow for large, multi-file, or long-context tasks, but users should expect to rely on the included references and examples rather than a highly polished turnkey install experience.
- Explicit triggers for large-document and multi-file work make the skill easy for an agent to recognize and invoke.
- Substantial body content with 13 H2s, 7 H3s, code fences, and concrete references provides reusable decomposition guidance instead of a placeholder.
- Examples and decision rules for when to use recursive vs. direct processing improve agent leverage on codebase analysis and document aggregation tasks.
- No install command and no supporting scripts mean adoption depends on reading the SKILL.md and references rather than running a packaged workflow.
- Placeholder markers are present, so some sections may still be incomplete or need refinement before users can trust it for edge cases.
Overview of recursive-decomposition skill
The recursive-decomposition skill helps you solve large, multi-file, or multi-hop tasks by splitting work into smaller parts, processing them independently, and then merging the results. It is most useful for recursive-decomposition for Workflow Automation, codebase-wide review, and multi-document extraction when a single prompt would be too shallow or too fragile.
What this skill is for
Use the recursive-decomposition skill when the job is not “answer a question,” but “analyze a large body of material reliably.” Typical fits include scanning many files, comparing patterns across a codebase, extracting structured facts from many documents, or building a consolidated report from distributed sources.
Why it is different from a normal prompt
A normal prompt asks the model to hold everything in one pass. This skill pushes you toward progressive disclosure: narrow the search space first, then recurse into the relevant pieces, then synthesize. That is the main advantage when context rot, missed files, or inconsistent aggregation would otherwise hurt output quality.
Best-fit use cases
The recursive-decomposition skill is a strong fit when you have 10+ files, 50k+ tokens, or a task that needs systematic coverage rather than a quick summary. It is weaker for small, localized questions where direct processing is cheaper and faster.
How to Use recursive-decomposition skill
Install and activate it
For recursive-decomposition install, add the skill to your Claude Code or skills-enabled workflow, then call it when the task clearly exceeds single-pass context. The repo’s SKILL.md points to supporting references in references/, which is where the practical decision rules live.
Start from the right input
Give the skill a target, a scope boundary, and an output format. Strong input looks like: “Analyze error handling across src/api, src/services, and src/utils; return a table of patterns, gaps, and recommendations.” Weak input looks like: “Review this repo.”
Read these files first
For recursive-decomposition usage, start with SKILL.md, then inspect references/cost-analysis.md, references/codebase-analysis.md, references/document-aggregation.md, and references/rlm-strategies.md. Those files show when to recurse, how to partition work, and how to aggregate results without losing structure.
Workflow that gets better results
Use this sequence: define scope, identify candidate files or documents, filter aggressively, batch the remaining items, run parallel sub-tasks, then synthesize findings into one schema. The recursive-decomposition guide is most effective when you specify what should be excluded, what counts as evidence, and how the final output should be organized.
recursive-decomposition skill FAQ
When should I use recursive-decomposition?
Use it when the task spans many files, many documents, or a large token budget, and completeness matters more than speed. If the work is local, narrow, or already well-scoped, direct processing is usually enough.
Is recursive-decomposition only for codebases?
No. The same pattern works for codebases, research notes, PRDs, long reports, and other document sets. The key requirement is that the task benefits from filtering, partitioning, and aggregation.
What is the main failure mode?
The most common failure is using recursive-decomposition on an underspecified task. If you do not define the target set, output format, or acceptance criteria, the skill can recurse efficiently but still produce an unfocused result.
Is this skill beginner-friendly?
Yes, if you can describe a concrete goal and a scope boundary. Beginners usually do best when they ask for one deliverable, such as a gap analysis, inventory, or comparison, instead of an open-ended exploration.
How to Improve recursive-decomposition skill
Give the skill a tighter search frame
The best recursive-decomposition usage starts with a bounded question. Instead of “review the repository,” say “find all error handling patterns in src/api and src/services, note inconsistencies, and summarize by module.” Tight framing reduces noise and makes recursion worth the overhead.
Provide an extraction schema
If you want structured output, say what each item should contain. For example: file, pattern, severity, evidence, and recommendation. This helps the skill keep parallel sub-results comparable instead of narrating them differently.
Be explicit about thresholds and exclusions
The repository’s decision logic emphasizes token count, file count, and whether quality matters more than latency. If you know your constraints, say them: “exclude tests,” “ignore archived docs,” or