stack-prslisted

# Stack PRs The output of this skill is a **proposal**: an ordered stack of PRs, presented for the user to approve, reshape, or reject. Cutting branches happens in the last step, and only on their word. ## What makes a stack A **stack** is an ordered chain of PRs, each based on the one below it. Two properties make it worth the extra branches: - **Ordered** - a PR may only build on what sits below it in the stack. A change that needs something from a later PR belongs lower, or in the same one. - **One context per PR** - each PR carries a whole context: a behavior, an area, a layer, plus everything that makes it make sense on its own. A reviewer judges it without reading the rest, and it leaves the branch green. Common seams, roughly in stack order: shared setup (fixtures, helpers, config) below the code that uses it; refactors below the behavior change they enable; mechanical or generated edits apart from hand-written ones; then one PR per feature, route, or area. Context is the unit, never the file. Splitting by path produces PRs a reviewer has to reassemble in their head, and reviews worse than the one big PR it came from - so a file that only makes sense next to its neighbor ships with it. Three to five PRs is a healthy stack. ## Workflow ### 1. Gather the changes Establish what is in play: the base branch, and whether the changes are committed on a branch, staged, or loose in the working tree. Read the actual diff - hunk by hunk, not the file list. **Done when**