github-evidence-triage

To triage a GitHub pull request with evidence links, you provide the PR URL to generate a structured report mapping the issue to code, tests, docs, and git history. It separates reporter claims, maintainer statements, and inferred risks using stable references like URLs, commit SHAs, and file line ranges.

Assessing PR risk without modifying the repository requires a strict read-only analysis that prohibits commenting, labeling, reviewing, or merging. This approach evaluates debugging reproducibility and maps changed files to repository artifacts while mandating every factual claim be supported by stable evidence references.

Read-only GitHub issue triage supports linking issues and PRs to relevant repository artifacts including code, tests, docs, and git history. It connects the issue to changed files and commits when needed for the analysis, ensuring all findings are backed by stable references such as URLs or commit SHAs.

You can use issue triage to summarize debugging reproducibility by evaluating the GitHub issue discussion and mapping it to repository artifacts. The triage applies a structured output contract with STATUS, EVIDENCE, FINDINGS, RISK / IMPACT, and UNVERIFIED sections to clarify reproducibility status.

Mapping an issue to repository artifacts requires every factual claim to be supported by stable evidence references such as URLs, commit SHAs, file line ranges, or fresh read outputs. This strict evidence rule separates verified facts from inferred risks and unverified items in the final triage report.

You should not use automated GitHub issue triage when you need to execute write actions like commenting, labeling, reviewing, or merging on the GitHub repository. This approach is strictly read-only and focuses solely on producing a source-grounded assessment without modifying the issue or pull request state.