git-spec-planlisted

# Spec Plan converged plan -> survey repo -> decompose -> check disjointness -> parent issue -> sub-issues -> native links -> print tree. **Planning is sequential and stays with you.** Never fan decomposition out to agents. Why -> deciding task boundaries needs whole-repo context in one head, and every task's `files:` set depends on the ones already assigned; parallel planners produce overlapping slices that cannot be reconciled after the fact. Only execution fans out, and that is `git-spec-dispatch`'s job. Bodies obey **Length** below. Labels resolve through the chain below, never hardcoded. ## Flow 1. **Establish the change.** What, why, done-when. Thin or ambiguous input -> ask before writing anything. Why -> a spec tree built on a guess costs more to unpick than to ask: every sub-issue, every `files:` set, and every branch downstream inherits the wrong scope 2. **Survey the repo for real file boundaries.** Read the module layout (`ls`, the project's `CLAUDE.md`/`README`, the entry points). Find the seams - where does one module stop calling into another. Check what already exists so a task says "extend" rather than "add" a thing already there. Grep for the nouns the user used. Why -> this is what makes `files:` accurate rather than aspirational, and an aspirational `files:` is a clobber waiting to happen in wave 1 3. **Decompose into tasks.** Each task is a vertical slice that leaves the tree green on its own - it builds, it passes `verify:`, it could ship alone. Pre