Decompose
Use when a goal is too large to tackle as one unit. Splits into 3-6 bounded sub-parts with clear scope boundaries. Keywords: break down, split, subdivide, decompose, plan, areas, parts.From its SKILL.md
npx -y skills add tyevans/tackline --skill decomposeAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 14 stars14 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
2.3 KB, as published. Nobody here has run it
Decompose: Break Into Bounded Sub-Parts
You are running the decompose primitive — breaking a goal or topic into bounded sub-parts with clear scope. Target: $ARGUMENTS
When to Use
- When a goal is too large or vague to tackle as a single unit
- Before fan-out workflows (fractal, blossom) to identify investigation areas
- After gathering to split findings into workable chunks
- When the user asks to "break down", "split", or "plan" an approach
Process
- Identify the whole: Parse $ARGUMENTS or detect upstream pipe-format output in context.
- Search for structure: Use Grep/Glob/Read to understand the codebase's actual structure relevant to the topic. Ground decomposition in reality, not speculation.
- Split into sub-parts: Identify 3-6 bounded sub-parts that are MECE (mutually exclusive, collectively exhaustive).
- Assess isolation: For each sub-part, compare its
scope(file patterns) against all other sub-parts. If their file sets are disjoint, markindependent; if any files overlap, markshared-state. When uncertain, default toshared-state(conservative). Downstream skills (/plan, /sprint) use this field to decide whether to parallelize via worktree isolation or serialize.
Output Format
Output in pipe format. Each item includes:
- Scope: what's included
- Boundary: what's explicitly excluded
- Isolation:
independent(disjoint file sets, safe for worktree isolation) orshared-state(overlapping files, must serialize or merge)
Guidelines
- Target 3-6 sub-parts. Fewer means the goal wasn't complex enough; more means sub-parts are too granular
- Each sub-part must be independently investigable — no sub-part should require another to make sense
- Boundaries matter more than scope — ambiguity lives at the edges
- Ground in codebase structure when decomposing code-related goals
- For
isolation: non-overlapping scope file patterns →independent; any shared files →shared-state; doubt →shared-state