# Code review

> Check the outcome, resolve findings and approve the change that will merge.

Develop and review · /code-review/ · 2026-11-05

## 1. Run the PR review

**Codex**

```text
$neutron:pr-review Review [PR URL] against its linked Jira ticket. Read the description, acceptance criteria and comments through the connected Jira MCP or authenticated acli; ask for pasted details if unavailable.
Return actionable findings with file and line references, impact, supporting evidence and verification gaps for the current PR commit. Keep the review read-only.
```

**Claude Code**

```text
/pr-review Review [PR URL] against its linked Jira ticket. Read the description, acceptance criteria and comments through the connected Jira MCP or authenticated acli; ask for pasted details if unavailable.
Return actionable findings with file and line references, impact, supporting evidence and verification gaps for the current PR commit. Keep the review read-only.
```

- Run this skill in a fresh review session with the PR, ticket and repository instructions so the agent forms its own assessment.
- Confirm the review covers the latest PR commit and the correct [Jira ticket](/deliver-a-change/#1-understand-the-ticket).
- Prioritize incorrect behaviour, permission gaps, data loss, regressions and [new or upgraded dependencies](/security/#r-sec-2). Leave formatting to repository checks.

## 2. Check findings and fix defects

- **AI-3** (medium risk; checked by code review): **Check tests against the acceptance criteria.** An agent can write code and tests that share the same wrong assumption.
- **PR-4** (high risk; checked by code review): **The owner can explain every change and its failure modes.** Agent authorship does not transfer accountability.

Scenario: the review of the ENG-123 PR returns twelve findings.

**Bad prompt**

```text
Fix all the review comments.
```

**Better prompt**

```text
For each finding, reproduce it or show why it is wrong, with evidence. Fix only confirmed defects and add a test for each. List dismissed findings with the reason. Don't change code the findings don't touch.
```

Why: a review comment is a claim, not proof. Fixing everything blindly adds churn and can break code that was correct.

- Check that each confirmed defect has a fix and a test, and each dismissed finding has evidence.
- Rerun affected checks and repeat the review after material changes.

> **Example: ENG-123 · Review finding**
>
> A non-admin can export orders from their merchant. The export endpoint checks merchant ownership but not admin permission.
>
> - Reproduce: sign in as a non-admin and call the export endpoint directly. It queues the export, and the download link returns the file; the ticket requires denial.
> - Why the PR evidence missed it: the permission test checked only that the export button is hidden for non-admins. The code and the test shared the same assumption.
> - Fix: enforce admin permission on the server and add a denied-access test. Hiding the button leaves the endpoint accessible.

## 3. Approve and merge

- **PR-3** (medium risk; checked by CI): **Required CI checks must pass for the reviewed commit.** Inspect skipped jobs and report-only findings; a green summary can hide missing evidence.
- **PR-6** (high risk; checked by agent settings and CODEOWNERS): **One human approval before merge; AI review is advisory.** The project decides who may approve, and branch protection enforces it.

* Check the project's runbook for who may approve. The approver reviews the final diff and evidence and confirms the target branch.
* Resolve blocking findings before merge. Deferred release checks need an owner and linked ticket; complete them before release.
* Merge the approved PR into the agreed target branch.

Next: Hand the merged commit, remaining release checks and recovery notes to [Release and close out](/release-mgmt/).