---
name: review-methodology
description: pragent review methodology — severity rubric, what to report vs skip, anchoring rules, and how to honor repo focus. Load this before reviewing a PR.
---

# pragent review methodology

## Severity rubric

- **critical** — exploitable security bug, data loss/corruption, or a crash on
  a normal input path. Must fix before merge.
- **high** — correctness bug on a real input path, broken contract, or a
  missing test for security/error behavior. Should fix before merge.
- **medium** — likely bug on an edge case, missing test for changed logic, or a
  risky pattern that isn't broken yet. Worth fixing.
- **low** — minor risk, stale expectation, or a defensive improvement. Nice to
  have.

## Report vs skip

**Report:** correctness bugs, security problems, risky changes, missing tests
for changed behavior, breaking API/contract changes, N+1/O(n²) in hot paths.

**Skip:** praise, nitpicks, pure formatting/style, personal preference,
speculative "what if" without a concrete trigger, anything already covered in
`prior_reviews`.

Cap at ~15 findings, highest severity first. Quality over quantity — an empty
findings list for a clean diff is a correct result.

## Anchoring (for inline comments)

Each finding's `line` MUST be a line that exists in the POST-CHANGE version of
`path`:
- a **context** line (unchanged, shown with a leading space in the diff), or
- an **added** line (shown with a leading `+`).

Never anchor on a **removed** (`-`) line — it has no post-change line number.
If you're unsure of the exact line, use the closest context line you CAN see in
the diff. A misanchored finding becomes a summary bullet instead of an inline
comment, so correct anchoring is what gets a finding shown inline with its
suggested-fix code block (language-highlighted) rather than demoted to a bullet.

## Ground each finding in context

Don't flag a hunk in isolation. For each changed file, read its callers,
imports, sibling functions, and type definitions (the repo is checked out at
the head sha), and make sure the finding holds against how the change is
actually used. Keep it bounded — 1–3 related files per finding, no unbounded
whole-repo walks.

## Honoring repo config

If `.pr-review.json` is present, honor it:
- `focus` — weight these areas higher, but never ignore a critical issue
  outside them.
- `exclude_paths` — skip findings in these paths.
- `languages` — hint to the primary languages; pick matching linters.
- `instructions` — house conventions / compliance language; treat as binding
  reviewer rules.

## Linters are a signal, not the verdict

Run the repo's own typecheck/lint on changed files, but translate their output
into human findings — a raw `TS2322` is not a review comment. Correlate
diagnostics with the diff; ignore diagnostics in files the PR didn't touch.