issue-to-prlisted

# GitHub issue → PR Two jobs, in this order: **decide what deserves code**, then **write it**. Most of the value is in the first job — an issue implemented that shouldn't have been is worse than one left open. Hard rule: **the verdict table is a stop.** Never move from triage into implementation without the user naming the issue to build. This skill is user-only (`disable-model-invocation: true`) and the rule above is load-bearing — do not relax it to enable automation. The unattended path is the separate `loop-issue` skill, where applying the `loop:go` label is the maintainer's naming act. ## Stage 1 — Sweep ```bash gh issue list --state open --limit 50 \ --json number,title,labels,author,createdAt,comments,body ``` Zero open issues → say so and stop. Don't invent work. Set aside (report as skipped, one line each, no triage effort): - an open PR already links it — check `gh pr list --state open --json number,title,body` - labeled `wontfix` or `duplicate` - labeled `question`, and the last comment is yours/the maintainer's — the reporter owes a reply ## Stage 2 — Classify Every remaining issue is exactly one of: **bug**, **feature**, **docs**, **not-actionable** (support request, unrelated tool, no content). Label the issue carries ≠ the classification. A reporter's "bug" that asks for new behavior is a feature. Judge from the body, not the label. ## Stage 3 — Evaluate ### Bugs — repro first, verdict second No reproduction, no `REAL` verdict. In order: 1. Fin