issue-worklisted

# Issue work ## Inspect ```bash # REST reads — see ~/.claude/CLAUDE.md "GitHub API budget". gh api repos/:owner/:repo/issues/<N> \ --jq '{title, body, milestone: .milestone.title}' # body + milestone gh api repos/:owner/:repo/issues/<N>/comments --jq '.[].body' # comments gh issue develop <N> --list # linked branches (no REST equivalent, one call/pickup) gh search prs "(<N> in:body) OR (<keywords> in:title,body)" \ --repo <owner>/<repo> --state all --limit 20 \ --json number,title,state,url # open → in-flight PR (takeover candidate); merged → scope already covered, even if unlinked # Milestone gate: issue's milestone (above) vs the current (lowest-version open) one gh api repos/:owner/:repo/milestones --jq '.[].title' | sort -V | head -1 # none or current → fine to work; a different (later) milestone → no-go ``` For recent commits in the area: - Path-scoped: `git log --oneline -- <path>` over files the issue names. - Otherwise: `git log --oneline --since=<issue createdAt>` over the likely subsystem. ## Reproduce (bug-typed issues) Attempt repro on the default branch before writing the fix: - A confirmed repro becomes the failing test the fix has to flip. - A failed repro is itself a staleness signal — issue may be obsolete. - If repro is hard because the harness for this code path doesn't exist, surface it. Tiny harness lifts can land inline; anything bigger files separately and waits for direction. ## Staleness signals