Guide

How to Set Up Autonomous AI Pull Request Review

Name: Fleet
Author: Fleet

Getting a pull request reviewed is often the slowest step in a development cycle. An autonomous reviewer agent can handle routine structural checks — test coverage, naming conventions, obvious logic errors, diff scope — in seconds, freeing human reviewers for architectural decisions and business logic judgment calls.

Fleet ships a /fleet-review-pr skill that reviewer agents run automatically when a PR enters the needs-review state. The reviewer checks out the branch, runs the review skill, publishes a pr_approved or pr_changes_requested fabric event, and optionally posts a GitHub comment. This guide shows how to wire that up.

Before you start

Fleet watcher running in your repository
A `tech-lead`, `qa-engineer`, or `pr-reviewer` role agent defined in `.fleet/config.yaml`
Fleet skills installed: `fleet skills install`
GitHub CLI authenticated with read access to pull requests

1

Define a reviewer agent

Add a reviewer agent to your config with a reviewer role such as tech-lead, qa-engineer, or pr-reviewer. The role tells Fleet to inject the /fleet-review-pr skill directive into the agent's handbook prompt. You do not need to mention the skill in the agent's own prompt file.

agents:
  - name: tech-lead
    role: tech-lead
    department: engineering
    reports_to: cto
    model: claude-opus-4-5
    subscribes_to: pr_needs_review

2

Install Fleet skills

The /fleet-review-pr skill lives in the Fleet binary and must be synced to your ~/.claude/skills/fleet/ directory. Run fleet skills install after every Fleet upgrade to keep the skill files current.

fleet skills install
# Verify
fleet skills list

3

Trigger a review by adding a label

When a developer opens a PR and adds the needs-review label, the watcher publishes a pr_needs_review fabric event. The reviewer agent auto-starts, runs /fleet-review-pr, and publishes its decision. You can also trigger manually for testing.

# Trigger via label
gh pr edit 57 --add-label needs-review

# Watch the event log
fleet log --type decision --agent tech-lead

4

Understand the self-review constraint

GitHub prevents authors from approving their own PRs. Fleet's review skill is designed for this: it publishes the pr_approved fabric event regardless of whether the formal gh pr review --approve command succeeds. The fabric event is the source of truth for the merge gate.

# The reviewer skill always publishes the fabric event:
# fleet fabric publish --event pr_approved --sender tech-lead \
#   --summary "Approved PR #57" --payload '{"pr": 57}'
# The release-manager reads this event, not GitHub's reviewDecision

5

Verify the review decision in the log

Use fleet log to confirm the reviewer published a decision event. Look for pr_approved or pr_changes_requested in the output. If neither appears, the agent exited without completing the skill — check the tmux session for errors.

fleet log --type decision --since 1h

Common pitfalls

The reviewer agent is not a replacement for human review on security-sensitive or architecture-changing PRs. Use it for the first-pass structural check, not as the sole gatekeeper.
If skills are not installed or are stale, the reviewer agent will not know how to run `/fleet-review-pr`. Always run `fleet skills install --dry-run` first when debugging a reviewer that seems to do nothing.
A PR where the diff looks like it deletes features is often a stale-base issue. The reviewer skill checks out the branch, but a stale base can make `gh pr diff` misleading. Verify with `git merge --no-ff` before issuing changes-requested.
The `pr_changes_requested` event re-queues the developer agent for another round. If the dedup receipt is not cleared, the re-dispatch silently fails. This is tracked as a known issue.

When Fleet is the right tool

Autonomous PR review with Fleet is a good fit when you have a team of Claude Code developers generating PRs faster than humans can review them, or when you want consistent structural checks applied to every PR regardless of reviewer availability. It is not a good fit when your review process is primarily about business logic validation that requires deep domain knowledge Fleet does not have.

Frequently asked questions

Will the reviewer agent post comments on the GitHub PR?

Yes, if the `/fleet-review-pr` skill determines there are actionable findings. It posts structured review comments via the GitHub CLI. If it approves, it may post a brief summary comment.

Can I have multiple reviewer agents with different focuses?

Yes. Define multiple reviewer agents and give each a different system prompt that focuses their attention (security, performance, test coverage). Each subscribes to the same `pr_needs_review` event. Fleet's concurrency cap prevents all of them from starting simultaneously if you set an agent cap.

Run your first agent fleet

One binary. Five minutes. See every agent, coordinate every handoff, and keep a full audit trail of what your fleet did.

See how it works Install Fleet