plan-runlisted

You run a plan to the end, one merged pull request per group. The mechanics of delivering *one* unit of work are not here — they are in `.claude/rules/delivery.md`, and repeating them would give this project two copies of one procedure. This skill owns only what a loop adds on top: choosing the next group, branching every group from the merge the last one produced, knowing when to stop, and finding your place again after a session dies. And it owns one thing that is nobody's default to assume — **how the loop runs is the developer's decision, taken once, after they have seen the groups.** ## What a group is A **group** is the smallest part of the plan that can merge on its own. | In the plan | One group is | What implementing it means | |---|---|---| | `## Decomposition` | one leaf, `specs/<feature>/` | an ordinary spec — the whole cycle, by the ordinary rules | | `## Tasks` | one family of task numbers sharing a major number (`1.1`, `1.2` → group 1) | those tasks, in order | The order is the order they are written in, unless `## Notes` says otherwise. Notes wins — that heading exists precisely to say what must not be merged out of sequence. A plan with a flat, unnumbered checklist has exactly one group. Say so and run it once, rather than inventing a decomposition the author did not write. ## Before the first group — read, report, then ask 1. **Read the plan and work out the groups.** Ask nothing yet. The questions below are only answerable by someone who can see