Run a Code Review on Your Branch

What you'll learn

• How to run a structured code review on any branch before opening a pull request
• How to read and act on severity-grouped review findings
• How to ask the agent to fix specific findings automatically
• How to focus reviews on security, performance, or other specific areas

Before you start

• Autohand Code installed. Run autohand --version to confirm. See Your First Autohand Session if you need to install it.
• Your changes are committed on a branch. The review compares your branch to the base branch (usually main or master). Uncommitted changes are not included.
• The branch has diverged from the base. You need at least one commit with your changes for the diff to compare.
• The base branch is up to date locally. Run git fetch origin main before starting a review to diff against the latest version of the base.

Start the review

From inside your project directory, run the skill with a single command.

autohand "/review-pr"

The agent runs git diff origin/main...HEAD to get the changeset, reads every modified file to understand the surrounding context, then produces a structured review. You will see it work through the files one by one.

Reading: src/services/payment.js
Reading: src/services/payment.test.js
Reading: src/utils/retry.js
Analyzing changes across 3 files...

The review arrives as a formatted report, not a stream of thoughts. It is organized by severity and category so you can act on the most important items first.

Understanding the review output

The review output groups findings into severity levels. Here is what each level means and what a finding looks like.

CODE REVIEW: feat/payment-retry
3 files changed, +127 lines, -14 lines

CRITICAL (1)
  src/services/payment.js:43
  The retry loop has no maximum attempt limit. If the payment
  provider is down, this will retry indefinitely and block the
  event loop. Add a MAX_RETRIES constant and break out of the
  loop when it is exceeded.

WARNINGS (2)
  src/services/payment.js:67
  The error is swallowed after logging. Callers receive undefined
  instead of a rejected promise. Throw the error or return a
  Result type so callers can handle failures.

  src/services/payment.test.js:12
  The test for the retry path only tests a single retry. It does
  not test the maximum retry boundary. Add a test for the case
  where retries are exhausted.

SUGGESTIONS (3)
  src/utils/retry.js:8
  The exponential backoff multiplier is hardcoded to 2. Consider
  making it configurable so callers can adjust the backoff curve.

  src/services/payment.js:51
  Variable name "r" is too short. Rename to "retryCount" for
  clarity.

  src/services/payment.js:88
  This async function does not handle the case where the network
  request times out. Consider adding a timeout using AbortController.

The severity levels mean the following.

• Critical. Bugs, security issues, or patterns that will cause failures in production. Fix these before merging.
• Warnings. Code that works but has real problems: swallowed errors, missing test cases, incorrect behavior in edge conditions. Fix these unless you have a deliberate reason not to.
• Suggestions. Style, naming, and clarity improvements. These do not affect correctness but make the code easier to maintain. Address them if the effort is low.

Address the findings

Once you have the review, you can ask the agent to fix specific findings directly. Reference the finding by its file and line number.

autohand "Fix the critical finding in src/services/payment.js:43. Add a MAX_RETRIES limit of 3 to the retry loop and break out when it is exceeded."

You can also ask the agent to fix all critical findings in one go.

autohand "Fix all Critical findings from the review."

For warnings that require judgment, review them yourself. The agent flagged that the error is swallowed, but whether you throw, return a Result, or log-and-continue depends on how callers expect to handle failures in your codebase.

Re-run for verification

After addressing the findings, commit your fixes and run the review again. The second pass should come back clean or with only low-severity suggestions.

git add src/services/payment.js src/utils/retry.js
git commit -m "Address code review findings"

autohand "/review-pr"

A clean second pass means you are ready to open the pull request. The agent will confirm if it finds no new issues.

CODE REVIEW: feat/payment-retry
5 files changed, +143 lines, -18 lines

No critical issues found.

SUGGESTIONS (1)
  src/services/payment.js:51
  Consider adding a JSDoc comment to the retryPayment function
  describing the retry behavior and the MaxRetriesExceededError
  it throws.

Customize the review focus

The default review covers everything. If you want the agent to focus on a specific area, pass instructions alongside the command.

autohand "/review-pr Focus on security issues only. This code handles payment data."

autohand "/review-pr Check for performance problems. This endpoint is called on every page load."

autohand "/review-pr Review only the test files. I want to make sure the tests are thorough and cover the right cases."

You can also ask the agent to review against a specific standard that your team follows.

autohand "/review-pr Our convention is to use Result types instead of throwing exceptions. Flag any code that throws directly."

Focused reviews are faster and produce less noise. Use them when you already know the high-risk area of your change and want a targeted pass rather than a full audit.

What you learned

• Ran a structured code review on a feature branch using /review-pr
• Read and prioritized findings grouped by Critical, Warnings, and Suggestions
• Used the agent to fix specific findings by referencing file and line number
• Customized the review focus for security, performance, or team conventions

Try next