Develop and review / Code review
中文

Code review

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

Updated 5 Nov 2026View as markdown
On this page

1. Run the PR review

Skill pr-review
Codex
$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
/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.
  • Prioritize incorrect behaviour, permission gaps, data loss, regressions and new or upgraded dependencies. Leave formatting to repository checks.

2. Check findings and fix defects

  • Check tests against the acceptance criteria. An agent can write code and tests that share the same wrong assumption.
  • 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
Fix all the review comments.
Better prompt
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.
ExampleENG-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

  • Required CI checks must pass for the reviewed commit. Inspect skipped jobs and report-only findings; a green summary can hide missing evidence.
  • 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.