name	least-to-most
description	For a complex problem, first decompose it into an ordered list of simpler subproblems, then solve them in sequence, feeding each answer into the next, instead of one-shotting the whole thing. Use on multi-step tasks, hard algorithmic problems, or anything that fails when attempted whole. Trigger with /least-to-most or "break this down", "decompose first", "solve step by step in order".
version	0.1.0
user-invocable	true
metadata	{"emoji":"🪜"}

least-to-most

Hard problems fail when attempted in one leap. Decompose into ordered subproblems (easiest/foundational first), solve each using the answers from the earlier ones, then assemble. Explicit decomposition, sequential solving.

Why this exists (evidence)

Least-to-most prompting (Zhou et al., arXiv:2205.10625): decompose-then-solve-in-sequence generalizes to harder problems than chain-of-thought, with large gains on compositional generalization (e.g. SCAN) and multi-step reasoning, precisely because later steps build on solved earlier ones.
It targets the failure where a model can do each step but botches the leap when forced to do them all at once.

When to use

Multi-step tasks where step N depends on step N-1 (migrations, multi-file refactors, algorithmic problems, data pipelines).
A task that keeps failing when attempted whole.
NOT for simple or already-atomic tasks (decomposition is overhead there).

The method

Decompose: list the subproblems in dependency order, simplest/foundational first. Make the ordering explicit (each item names what it needs from prior items).
Solve in sequence: solve subproblem 1; carry its concrete answer into subproblem 2; and so on. Do not skip ahead.
Assemble: combine the sub-answers into the full solution.
Check the seams: verify the points where one sub-answer feeds the next (that is where composition errors hide).

How to run it

Inline: write the ordered subproblem list, then solve down the list.
For code: decompose into the ordered edits/functions; implement+verify each before the next (composes with TDD/testsmith per step).
Distinct from orchestrate (which is the plan->spec->build->verify dev cycle with a gate); least-to-most is the reasoning-decomposition technique you can use INSIDE any step.

Composes with

orchestrate: least-to-most is how you fill the PLAN step.
reflexion: if a subproblem fails, reflect before retrying that one (not the whole chain).
self-consistency: sample the decomposition itself when the right breakdown is unclear.

Honest limits

A wrong decomposition propagates: if the ordering/breakdown is off, every step inherits it. Sanity-check the decomposition before solving.
Overhead on simple tasks; scope to genuinely compositional problems.
Gains are on the paper's benchmarks; measure your own.

least-to-most

Why this exists (evidence)

Least-to-most prompting (Zhou et al., arXiv:2205.10625): decompose-then-solve-in-sequence generalizes to harder problems than chain-of-thought, with large gains on compositional generalization (e.g. SCAN) and multi-step reasoning, precisely because later steps build on solved earlier ones.

It targets the failure where a model can do each step but botches the leap when forced to do them all at once.

When to use

Multi-step tasks where step N depends on step N-1 (migrations, multi-file refactors, algorithmic problems, data pipelines).

A task that keeps failing when attempted whole.

NOT for simple or already-atomic tasks (decomposition is overhead there).

The method

Decompose: list the subproblems in dependency order, simplest/foundational first. Make the ordering explicit (each item names what it needs from prior items).

Solve in sequence: solve subproblem 1; carry its concrete answer into subproblem 2; and so on. Do not skip ahead.

Assemble: combine the sub-answers into the full solution.

Check the seams: verify the points where one sub-answer feeds the next (that is where composition errors hide).

How to run it

Inline: write the ordered subproblem list, then solve down the list.

For code: decompose into the ordered edits/functions; implement+verify each before the next (composes with TDD/testsmith per step).

Distinct from orchestrate (which is the plan->spec->build->verify dev cycle with a gate); least-to-most is the reasoning-decomposition technique you can use INSIDE any step.

Composes with

orchestrate: least-to-most is how you fill the PLAN step.

reflexion: if a subproblem fails, reflect before retrying that one (not the whole chain).

self-consistency: sample the decomposition itself when the right breakdown is unclear.

Honest limits

A wrong decomposition propagates: if the ordering/breakdown is off, every step inherits it. Sanity-check the decomposition before solving.

Overhead on simple tasks; scope to genuinely compositional problems.

Gains are on the paper's benchmarks; measure your own.