| name | github-research |
| description | Verify which issues a PR solves via gh, not web search. |
| stack | vcs |
| tags | ["github","issues","verify","research","pr"] |
GitHub Research (verify matches)
When to use
"Does this PR fix issue X?", related issues, search issues in a repo.
Mechanical list/create → github-issues. This skill is mechanism match, not keywords.
Hard rule
Never use web_search or a browser to verify GitHub issues.
Use gh (or the GitHub API). Web snippets produce false "fixed" claims.
Procedure
1. Search with gh
gh issue list --repo OWNER/REPO --search "keywords" --limit 20 --state all
gh search issues "repo:OWNER/REPO keywords" --limit 20
2. Fetch full bodies
gh issue view N --repo OWNER/REPO --json number,title,body,state,labels
Do not judge from the title alone.
3. Mechanism cross-check (write it out)
For each candidate:
- What root cause / missing behavior does the issue report? (quote body)
- What does the PR do mechanically? (code path, not title)
- Does that mechanism address that root cause?
- Naming collision? Same word, different feature?
Only claim "solves #N" if the mechanism check passes. Else: "related, not verified".
4. PR linkage
gh pr view N --repo OWNER/REPO --json title,body,closingIssuesReferences,files
gh pr diff N --repo OWNER/REPO | head -200
Output style
- Verified fixes:
#N — reason
- Related only: separate list
- Non-matches: omit or one-line discard
Pitfalls
- Shared config field names are not the same bug
- Closed issues can still be the right historical match — read state