Read the review brief

For each pull request with a linked Claude Code session, Verity writes a review brief. It answers the questions the diff can't: what was asked, what the agent did, and how it knows the work is done. Open it from the button in the Verity comment on the pull request.

The brief doesn't grade the agent or say whether the code is correct. It points you at the places that need a person.

What the brief shows

• Asked. The task, or the plan when the prompt pasted one, with a short model-written version. Then the prompter's corrections and decisions along the way, each linked to its step.
• Look here first. At most five items, most serious first: a rule or guardrail that fired, a claim with no evidence, code with nothing run after its last change or whose last check failed, a test edited after a failing run, CI or test config changed, and work the agent said it left undone. A clean brief says "nothing flagged".
• How do you know? Each claim that work is done or a bug fixed, graded by the evidence between the last code edit and the claim:
  • shown: a test covering the change passed, or for a bug, the failing run now passes;
  • weak: only a build, typecheck or lint ran, or a changed language was never built or tested;
  • none: nothing verifying ran, the last test failed, or checks were skipped after a failure.
• Not from this session. Files with changes that no session edit explains, with their likely origin.
• Model summary. At most three sentences on intent, decisions, verification and leftovers, labelled as model-written.

Every item links to the step, command output or change behind it.

Guardrails

Verity also watches for a few rare, serious events. They appear under "Look here first" only when they fire:

• a test edited or deleted soon after it failed;
• test runner, CI or grading config edited when the task didn't ask for it;
• values from test expectations copied into code, or a test's inputs special-cased;
• a file or area the prompter ruled out changed in the pull request;
• destructive commands: force pushes, recursive deletes of the repository or a home folder, dropped tables, commands against production;
• a scratch, debug or verification script left in the pull request.

The report

• Review. Every change in review order: flagged files first, then code, tests, docs, changes not from the session, and lockfiles and generated files last. Each change shows where it came from, the steps that wrote it, and what ran after its last edit.
• Session map. The key steps by default: the prompter's turns, graded claims and their evidence, and edits to the pull request's files. Every step is one key away. Selecting a step shows its command and output, or its diff.
• Rules. When the repository has rules, they get their own tab.

A change made by a shell command (a code generator, sed) leaves no diff in the session. Its lines are marked as possibly written by a command the session ran, naming the run where it can.

A session linked by branch and time rather than by a commit trailer is marked inferred link. When one session covers several pull requests, each is briefed on its own part of the session.

Limited briefs

When Verity can't brief a pull request properly, the brief says it is limited and why, rather than implying all is well. Troubleshooting lists the reasons.

Keyboard

Who can open a report

Anyone signed in with GitHub who can read the repository. Access is checked with GitHub on every view, so removing someone from the repository removes their access. Reports expire after the organization's report retention (90 days by default).