work-issuelisted

Work a GitHub issue end-to-end. Two ways to pick the issue: - **`/work-issue <number> [base]`** — work that specific issue. - **`/work-issue next`** — pull the top item off the triage queue (the Projects board that [`/triage-issues`](../triage-issues/SKILL.md) populates) and work it. Use the base branch the user names; if none, default to `main`. ## 0. Pick the issue (`next` mode only) `next` reads the same board schema `/triage-issues` writes, so it needs the `project` scope on `gh` (`gh auth refresh -s project`). - Take the queue head — the `Ready` issue with the lowest `(Priority P0<P1<P2<P3, then Size XS<…<XL, then issue number asc)`: ``` gh project item-list <number> --owner <owner> --format json --limit 500 ``` Filter `status == "Ready"` and `content.type == "Issue"`, sort by those keys, take the first. `content.repository` (`owner/repo`) and `content.number` say which repo and issue to work; carry `effort` (the recommended model) to the hand-off in §6. - **Empty queue** → say so and stop. - On selection, flip the item to `Status = In progress` so a re-run of `next` — or a parallel session — won't grab the same issue. Then continue from §1 for that issue. ## 1. Fetch & assess - **Move to In progress first.** The moment you start investigating, flip the issue's board `Status = In progress` — before reading the thread or touching anything — so a parallel session won't grab it. In `next` mode this already happened at selection (§0); in `/work