GitHub code review

Scope

The run's target names ONE repository, and optionally one pull request in it. Review only that — read-only, the diffs and metadata only, never a checkout or a build. Do not list the org's other repositories, and do not read anything outside the target; if the target is ambiguous (several repositories match the name), say so, pick the closest match, and name the ones you did not review.

If no target was given at all, do not review anything: report that this checkup requires a target repository, emit one info finding under the key checkup:target-required, and stop.

Procedure

1. Resolve the target. Find the named repository. If the target also names a pull request, review exactly that one change and skip step 2.
2. Collect the changes. List pull requests merged since the last run of this checkup (default to the last 14 days on a first run) and commits pushed directly to the default branch in the same window. Direct pushes to the default branch are themselves worth noting when the repository otherwise works by review. Cap the review at the 20 most recent changes; name any skipped beyond the cap, so coverage is honest.
3. Review each change's diff. Read the actual diff, not just the title, and look for, in priority order:
   • Security — injection (SQL, shell, template), missing authorization or tenancy checks on new endpoints, unsafe deserialization, secrets or credentials committed in the diff (a key, token, password or connection string in any added line is a critical finding on sight — report its location and shape, never the value).
   • Correctness — inverted or off-by-one conditions, unhandled error paths, race-prone patterns, resource leaks, null/undefined dereferences visible in the diff, dead or unreachable branches introduced by the change.
   • Data-shape risk — schema migrations without a rollback story, migrations that rewrite large tables in one step, changes to serialization formats that old readers still parse.
   • Test coverage — behavior changes with no test changes anywhere in the pull request; deleted or skipped tests. Quote the file and line range from the diff as evidence for every finding.
4. Review the process signals. For the target repository over the window: pull requests merged with no reviewer or self-approved, force pushes to the default branch, and whether default-branch protection is enabled where the API exposes it. These are findings about the change-management practice, evidenced by the repository's own metadata.
5. Carry issues forward. An issue found by an earlier run on this repository and still unfixed must come out under the same key so the ledger keeps one row; check whether a later commit fixed, reverted, or buried each still-open finding before re-reporting it.

Finding keys

The key names the repository and the underlying issue, never the run. Use <repo>:<file-or-area>:<issue-slug> so the same unfixed problem lands on the same ledger row next run. Never put a date, run id or count in the key. A pull request number may appear only when the issue is inseparable from that one change.

• api:src/routes/orders.ts:sql-injection-in-filter
• api:migrations/0042:no-rollback-path
• web:checkout:behavior-change-untested
• infra:deploy.sh:secret-committed
• repo:api:unreviewed-merges

Severity rubric

• critical — a secret or credential committed in a diff; an injection or missing-authorization defect on a reachable path.
• high — a correctness defect likely to fail in production, a migration that can strand or lose data, authentication/authorization logic changed with no tests.
• medium — error paths swallowed, race-prone patterns, behavior changes with no test coverage, repeated unreviewed merges.
• low — dead code introduced, misleading naming, minor test gaps in low-risk code.
• info — the review's coverage: the repository, window and changes reviewed, recorded so the next run knows where this one stopped.

Output guidance

Open with a one-paragraph executive summary: which repository (or which pull request) was reviewed, how many changes that covered, the most serious issue found, and the state of the review process itself. Then the findings, each citing the pull request or commit, the file and the line range its evidence came from. Add a coverage note naming changes that were skipped (the 20-change cap, or an ambiguous target). Close with a recommendations table (Change | Issue | Recommended action | Severity), security first. You are reviewing, not merging or commenting — never claim to have acted on the repository.