docs: issue references are searchable and nothing says so

[grimmerk]

Searching by a GitHub issue reference already works exactly like a pull request — https://github.com/acme/service/issues/4242, acme/service#4242, #4242, pr:4242 — and nothing says so, anywhere. The author of the feature asked whether it could be added (2026-09-15), which is the strongest possible evidence that it is undiscoverable.

acme/service is a placeholder. The measurements below were taken against a real corpus whose repositories are private and are not named here.

It is already implemented

GitHub numbers issues and pull requests in one sequence, so #N never distinguished them; the only form that differs is the URL path, and (?:pull|issues) is in all four places that matter, shipped in #151 (d64b6d4):

where	what
src/session-search.ts PR_URL_RE	parses an issue URL into {number, repo}
src/session-search.ts prRefPatterns	matches /issues/N in a session's text
src/session-search.ts highlightNeedles	highlights /issues/N
src/enrichment-cache.ts PR_REF_RE	mines issue URLs out of the assistant's own messages

Tests cover it too (parsePrRef on an issue URL with a #issuecomment-1 tail, pr:https://github.com/o/r/issues/11 in a query, findPrRef on an issue URL, and an issue URL in the miner fixture).

Verified end to end against the live corpus on 2026-09-15, each spelling of one issue reference run through searchClaudeSessions:

query	sessions	time
https://github.com/<owner>/<repo>/issues/<N>	23	91 ms cold, 16 ms warm
<owner>/<repo>#<N>	23	16 ms
#<N>	23	16 ms
pr:<N>	20	14 ms
https://github.com/<owner>/<repo>/pull/<N>	23	14 ms

pr: returns three fewer because it is the strict level: it drops sessions whose only occurrence was a bare #N. The /pull/ and /issues/ URLs return the same set, since the number is what identifies the thing. Most of the matches carry reasons=assistant, i.e. they were found through references mined out of the assistant's own messages, which is the path the question was really about.

What is missing is only the telling

• README.md line 35 describes the operator as "a pull request in any spelling" and lists owner/repo/pull/137 and the /pull/ URL. Line 41's section heading is Finding a pull request.
• The in-app ? cheat sheet shows pr:147, owner/repo#147, https://github.com/…/pull/147, with no issue form.

Proposal

1. Say "a pull request or issue" in the README operator table and in that section, and add one issue-URL example beside the pull one. Note the one real asymmetry while there: has:pr is about the PR badge Claude Code writes into a transcript, and there is no issue equivalent, so has:pr stays PR-only by design.
2. Add an issue URL to the ? cheat sheet line.
3. Consider an issue: alias for pr: — identical behaviour, just a name that does not make a user assume issues are excluded. Cheap (one entry beside pr: in the parser), and it is the form someone will reach for first. Open question: whether a second name for one operator is worth the cheat-sheet space, or whether renaming the concept in the docs is enough.

Part of the Sessions tab work tracked in #144.

🤖 On behalf of @grimmerk — generated with Claude Code