nextlisted

## 1. Find the board *Canonical board-lookup — other kanban skills point back here.* ``` gh project list --owner <owner> --format json ``` This returns *every* project the owner has, not just ones tied to this repo — several returned is not automatic ambiguity. Filter to a title match (`"<repo> Board"`, matching `kanban-setup`'s naming) or to boards whose items link back to this repo. Exactly one match: use it. More than one: ask the user. None: check for a label-based pseudo-board (`status:todo`, `status:in-progress`, `status:in-review`, `status:done` labels). Neither exists: fall back to a **roadmap doc** (`ROADMAP.md`, `docs/roadmap.md`) whose ordering section ("Execution order" or similar) links issues — that ordering is the queue. Nothing at all: tell the user to run `kanban-setup` first. **Label fallback, first use:** these labels aren't created by GitHub. Whichever skill is about to apply one for the first time runs `gh label create status:<name> --color <hex> --force` right before the edit, with a fixed color per label: `todo` EDEDED, `in-progress` FBCA04, `in-review` 5319E7, `done` 0E8A16. `--force` updates an existing label instead of failing; the fixed `--color` keeps repeat calls a no-op (without it `gh` picks a random color each time). Skills that apply a status label reference this note instead of repeating it. ## 2. Check for a burning priority first ``` gh run list --branch <default-branch> --status completed --limit 1 --json conclusion,url ``` Look at