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.

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.

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.

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.

Tip: Do not spend time arguing with suggestions. If you disagree with a naming suggestion or a style note, ignore it. Spend your time on Critical and Warning findings, which represent real problems.

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.

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

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.

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

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.

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

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.

Tip: Make running /review-pr part of your personal workflow before every pull request. Catching a critical bug before review costs nothing. Catching it during review costs the reviewer's time. Catching it in production costs much more.

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

autohand "Generate unit tests for all the changes on this branch that are not yet covered by tests"