triage-backloglisted

# Triage the backlog ## What this does `create-issue` opens work, `implement-issue` builds it, `merge-pr` lands it — and `merge-pr` Step 6 opens more, because landing a PR is when deferred work becomes visible. That is a lifecycle with three inlets and no outlet: every issue that ever leaves the queue leaves through a PR, so the queue can only drain at the speed of implementation, while implementation is itself what fills it. This skill is the outlet. It reads the open backlog, works out which items are still real work, which are duplicates of a job already tracked, which were quietly fixed by something else, and which were **observations that got filed as commitments** — then puts a single proposed disposition per item in front of the owner and executes what they confirm. The doctrine comes from `review-followups`, which has always had this outlet for migration reports: closing by decision is *"a legitimate, documented state, never a silent deletion"* — the precedent being *"not pursued by decision, not by lack of capability"*. This skill applies that same idea to GitHub issues, where until now the only documented way out was to build the thing. ## Autonomy contract Unlike its siblings, this skill is **not** hands-off, and deliberately so. See [ADR 0005](../../docs/adr/0005-the-lifecycle-skills-run-hands-off-triage-backlog-does-not.md) for why: its irreversible act (closing an issue) is a judgement about intent, and intent belongs to the owner — unlike a merge, which i