Review every pull request

Pull requests sit for hours before anyone reads them, and the first round of comments is the same every time: a missing test, an unchecked error, a risky query. Hand that first round to a deputy. Every new pull request in acme/web gets a careful review within minutes, and your reviewers start from a change that was already read once.

Available when your administrator enables deputies and webhooks.

The result

• Feedback while the change is fresh. The review lands on the pull request minutes after it opens, while the author still has the context.
• The same standard on every change. The deputy follows your team’s review rules on every pull request, including the ones nobody had time for.
• Reviewers focus on design. The obvious findings are already in a comment, with files and lines, so people spend their time on the hard questions.
• A full record. Every review is a run with a transcript, so you can see what the agent read, which checks it ran and why it said what it said.

How it works

An engineer opens a pull request on acme/web. The Marshal GitHub App sends the pull_request.opened event to Marshal, and the event trigger on the PR Reviewer deputy matches it. The deputy starts a review run in a fresh space built from its manifest. The run clones the repo, finds the open pull requests it has not reviewed yet, reads each diff, runs the tests and the linter, and posts a review comment with gh. When it finds something that needs a human call, such as a change to the payment flow, it asks the deputy’s owner and waits. The question shows on Home and in Slack, and the run carries on when someone answers.

What you use

Build it

1. Connect GitHub events. An admin installs the GitHub package and the Marshal GitHub App, then connects the app from the GitHub card on Settings > Webhooks. See Connected apps.
2. Add a team GitHub credential. On Connections, connect GitHub with a Personal access token that has the repo scope, and set the Owner to your team. See Connect GitHub.
3. Create the manifest. Add claude-code, github and your repo’s toolchain, plus your Claude credential and the GitHub token. See Create a manifest.
4. Create the deputy. On Deputies, select New deputy, name it “PR Reviewer”, choose the manifest and set the Owner to your team. See Create a deputy and a mission.
5. Write the mission. Create a mission named review-pr with the prompt below. Select Dry run to check it, then Activate.
6. Review one at a time. In the deputy’s About card, set Runs at once, per mission to 1. Pull requests that open together wait in line, so no two runs review the same change. See Concurrency and the waiting list.
7. Add the trigger. Open the mission, select Event under Triggers, set Source to GitHub and Event to pull_request.opened. In When, enter the condition below and select Test against real events. Then select Create. See Run a mission on a schedule or event.
8. Open a pull request. A run appears on the deputy page with the trigger webhook, and the review lands on GitHub.

The condition:

event.repository.full_name == "acme/web" && !event.pull_request.draft

The mission prompt. An event trigger starts the mission without inputs, so the prompt needs none:

Review open pull requests in acme/web that have no review from you yet.
Skip drafts.

For each one:
1. Read the description and the diff.
2. Run the tests and the linter on the branch.
3. Post one review comment with gh: a one-line summary, the findings
   that matter (bugs, risky changes, missing tests) with files and
   lines, then optional nits.
4. Do not approve or merge.

If a change touches billing or authentication, ask me before you
comment, with the choices "Comment" and "Leave it to a human".

Make it yours

• Review every push. Add a second trigger on pull_request.synchronize, so the deputy reviews new commits too.
• Review on request. Bind to pull_request.labeled with the condition event.label.name == "ai-review". Only pull requests your team tags get a review.
• Point it at one pull request. Map pull_request.number from the event into a mission input with the API, and write the prompt around {{.pr}}. See Map event data into mission inputs.
• Teach it your rules. Put your review rules in the deputy’s Context, such as “flag every new SQL query without an index”. See Memory.

Next

Create a deputy and a mission to hire your reviewer.

Related

• Schedules and triggers
• Sending Marshal a webhook
• Answer a question from a run
• Nightly dependency upgrades