wmxscott/stacked-planning

Use when work is already known to span more than one pull request and has to be decomposed into an ordered stack of them, when a change has passed the PR size cap and is still growing, or when a stack is nearing a fourth PR with no written plan. Covers the decomposition and the plan artifact recording it — not deciding what to build, and not task-level planning inside a single PR.

Use when a plan in docs/plans/ already defines its work as stacks of PRs and the user asks to implement, execute, or continue it, or names one of its stacks or phases — orchestrates one subagent per PR in its own worktree, reviewing and landing each before dispatching the next. Orchestration above the PR boundary only — everything inside a single PR — its tests, its debugging, its review — belongs to the subagent doing it. Not for writing a new plan; see authoring-stacked-plans.

Use when starting work on a branch or worktree, when about to commit, when opening a pull request, or while a pull request's checks are still running — the branch, worktree and PR discipline every change goes through. Mechanics only — it does not judge whether the work is done, review the change, or decide whether a branch should be merged, kept, or discarded.

Use only when work will land as more than one pull request and it is genuinely unclear whether to write the stacked plan or execute one that already exists — a router between authoring-stacked-plans and implementing-stacked-plans. Not a general entry point for planning or design, and not for a change that fits in one PR.