run-issueslisted

# Run issues One thin runner session implements a range of issues end to end. Every worker and gate is a subagent with a fresh context. After launch the user is needed once: the merge read. Settled design decisions and the incidents behind them live in `decisions.md`, next to this file. Read it if you are tempted to change how the run works — not to run one. ## Scope argument `/run-issues 05` · `05-09` · `13c 20 14 22` (explicit list, run in that order) · `all` (every remaining `ready-for-agent` issue in tracker order). Run in the order given. Some issues depend on earlier ones and say so in their own file ("run NN first", "this assumes NN has landed"); most do not. A blocked issue stops its dependents, not the whole run — see the per-issue loop. For `all`, resolve the scope from each issue file's `Status:` line and take only clean `ready-for-agent` issues. Print the resolved list in the launch message. Skip `ready-for-human`, `in-progress`, `needs-*` and anything `done`. If a `ready-for-agent` issue looks superseded by merged work, set it `needs-harden` with one line of why and skip it — never build a stale issue blind. `needs-harden` is the return path: `/harden-issues` takes it as in-scope. ## Who runs what Each role is a registered agent type carrying its own brief, model and effort. Spawn by `subagent_type`; the runner never pastes a brief. | Stage | Agent type | Effort | |---|---|---| | Implement | `run-issues-implementer` | high | | Third attempt after two rej