feat: Step 0 resolves a bare number to an issue OR a pull request

This skill is used for TODO.md items and for refactors that never had an issue,
so "issue number" was too narrow a contract. Step 0 already keys off observable
state; a PR is simply another entry point to it, and the stronger one -- it
carries the branch, the diff, the `## Scope assessment` and the review verdict,
which is everything Step 0 reads.

No flag is needed. GitHub numbers issues and PRs from ONE sequence per
repository, so a bare number is unambiguous: try `gh pr view <n>`, fall back to
`gh issue view <n>`. An earlier draft used `--pr <n>`; that distinction carries
no information.

Why it matters beyond tidiness: scripts/backlog-rhythm.sh hands unfinished
drafts back to this skill, and for a PR with no linked issue it had nothing to
hand -- it reported "no issue references this PR; finish it by hand". That left
every self-directed PR with no owner in the loop, which is how #620, #622 and
#623 all ended up driven by hand in one session.

Where an issue IS linked, nothing changes: it is still read for the diagnosis.
Where none is, Step 2's root cause comes from the maintainer's own framing
rather than a Stage 2 comment, and Step 9 records it in the PR body as usual.

Author: johanzander

.claude/skills/implement-issue/SKILL.md

@@ -24,6 +24,12 @@ the `bess-analyst` sub-agent.
 
 - User gives you a bess-manager issue number/URL and asks you to implement,
   fix, or resolve it locally.
+- **Or a PR number, or a `TODO.md` item, or a refactor with no issue at all.**
+  Issue-driven is the common case, not the only one. Step 0 resolves a bare
+  number to whichever it is, since GitHub numbers issues and PRs from one
+  sequence. Where there is no issue, the Step 2 diagnosis comes from the
+  maintainer's own framing rather than a Stage 2 comment, and Step 9 records it
+  in the PR body as usual.
 - Not for the `feature-lifecycle` multi-release integration flow (new
   inverter/price-provider platforms) — that skill owns experimental→stable
   graduation across multiple beta cycles. Use `implement-issue` for
@@ -67,11 +73,29 @@ runners — only repo-level `.claude/skills/` and `.claude/agents/` exist there.
 
 ## Process
 
-### 0. Resume check — is there prior work for this issue?
+### 0. Resume check — is there prior work for this number?
 
 Run this before Step 1, every time. A fresh issue costs one cheap check; a
 resumed one would otherwise lose work.
 
+**`<n>` may be an issue OR a pull request, and you resolve which.** GitHub
+numbers issues and PRs from one sequence per repository, so a bare number is
+unambiguous and no flag is needed. This is not an edge case: this skill is used
+for `TODO.md` items and for refactors that never had an issue, so a PR with no
+linked issue is the normal shape for that work, not a defect.
+
+```bash
+gh pr view <n> --json number,headRefName,isDraft,mergeable,reviews 2>/dev/null \
+  || gh issue view <n> --json number,title,labels,body,comments
+```
+
+If `<n>` is a **PR**, resume from it directly — it is the stronger handle,
+carrying the branch, the diff, the `## Scope assessment` and the review verdict,
+which is everything the table below reads. Read its linked issue too if it
+references one, for the diagnosis.
+
+If `<n>` is an **issue**, find its work the usual way:
+
 ```bash
 gh pr list --state open --search "<n>" --json number,headRefName,isDraft,mergeable,reviews
 git worktree list                       # a worktree already on this issue's branch?
@@ -719,6 +743,7 @@ net is upstream, not this section.
 | "the test asserts the exact command we write to hardware, that's precise" | Precise about the mapping, silent about the outcome. It stays green when the mapping is right and the physics is wrong. Assert realized cost / SoE / flows wherever an execution model exists. |
 | "it's green, so the fix works" | Green means the suite is satisfied. Revert the fix and watch the test fail — if it doesn't, it was never evidence. |
 | "this issue has no PR yet, so I'm starting fresh" | Step 0 checks branches and worktrees too, not just PRs. 8 abandoned branches in one audit had real commits and no PR — one with 32. Starting fresh from `origin/main` deletes them. |
+| "there's no issue for this PR, so it isn't mine to resume" | This skill covers `TODO.md` items and refactors, which never had an issue. A bare number resolves to either — that dead end left #620, #622 and #623 with no owner in the loop. |
 | "the old branch is a mess, cleaner to redo it" | Its commits are the only copy of a diagnosis you no longer have. If you genuinely cannot reconstruct the approach, that is a STOP-and-report, not a licence to reset. |
 | "that worktree's session shows dead, so it's mine to take" | Check unsandboxed. A sandboxed `claude agents --json` returned 1 session where the real answer was 17, because `~/.claude/jobs` is sandbox-denied — every other session read as dead. |
 | "the review said CHANGES_REQUESTED but nobody assigned it to me" | Nothing else will pick it up. Once the opening session exits, an orphaned PR has no owner at all — `sweep-prs` refuses the job by design. Resuming is how it gets one. |