---
name: evidence-github
description: Search GitHub for facts an analysis can cite - a known issue in a dependency, the PR that fixed it, what a release actually changed, prior art for a pattern. Use when a spec, review or triage needs to know whether a problem is already known upstream.
---

# GitHub as evidence

The `gh` CLI is already authenticated in this environment, which makes GitHub the cheapest citable source available: 5000 requests an hour, no new token, and results a reader can open.

## What to ask it

**Is this already a known bug?** Before writing a workaround into a spec, check whether upstream has one.

```bash
gh search issues --repo <owner>/<repo> --state all --limit 10 "<symptom keywords>"
gh issue view <n> --repo <owner>/<repo> --json title,state,body,closedAt
```

**Was it fixed, and where?** A closed issue without a linked PR is not a fix.

```bash
gh search prs --repo <owner>/<repo> --state merged --limit 10 "<keywords>"
gh pr view <n> --repo <owner>/<repo> --json title,mergedAt,files
```

**What did the release change?** Release notes beat a version-number diff.

```bash
gh release list --repo <owner>/<repo> --limit 10
gh release view <tag> --repo <owner>/<repo> --json name,publishedAt,body
```

**Prior art.** How other codebases solved the same thing, when the question is "is there a standard shape for this".

```bash
gh search code --limit 10 "<api or symbol>"
```

## Citing it

`GitHub:<owner>/<repo>#<number>` for an issue or PR, `GitHub:<owner>/<repo>@<tag>` for a release. Always the identity, never a bare URL: the identity survives a repo rename and tells the reader what kind of thing it is.

## What this is not

A closed issue is not proof the bug is gone in the version you ship. Check the release that carried the fix and the version the project actually depends on, and cite both. "Fixed upstream" without a version is the kind of claim that reads as settled and is not.