issue-worklisted

# Issue work ## Inspect `mcp__github__issue_read` (`method: get`) returns `closed_by_pull_requests`: the PRs declaring `Closes #N`, fork PRs included, each resolved to `OPEN`/`CLOSED`/`MERGED`. An open one is a takeover candidate. `references` holds at most five, so a `total_count` above that means the list is partial. The same call carries the body, milestone, and labels. Comments need a second call, `method: get_comments`. Unlinked work takes `mcp__github__search_pull_requests`, one call per field — joining them with `OR` drops a clause and reports no match: - `repo:<owner>/<repo> <N> in:body` - `repo:<owner>/<repo> <keywords> in:title,body` Ask for `fields: [number, title, state, pull_request]`. `state` reads `closed` on a merged PR, so `pull_request.merged_at` is what separates merged (scope already covered) from abandoned. Two lookups have no MCP equivalent: ```bash gh issue develop <N> --list # develop-flow branches # Milestone gate: the issue's milestone vs the current (lowest-version open) one gh api repos/:owner/:repo/milestones --jq '.[].title' | sort -V | head -1 ``` 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 s