Build a PR Reviewer Workflow in 10 Minutes

One of the most common tasks engineering teams automate with Swrly is PR review. Not replacing human reviewers — augmenting them. An AI agent reads the diff, flags potential issues, and routes the result to the right Slack channel. The human reviewer gets a head start. The team gets notified instantly.

In this tutorial, you will build this workflow from scratch. It takes about 10 minutes.

What You Will Build

A 5-node workflow that:

1. Triggers automatically when a PR is opened on GitHub
2. Runs an AI code reviewer that analyzes the diff
3. Checks whether the reviewer approved or flagged issues
4. Posts to #shipped if approved, or #reviews if changes are needed

By the end, you will have a fully automated PR review pipeline running on your own Claude Code subscription.

Prerequisites

• A Swrly account (free plan works)
• A GitHub repository you own or have admin access to
• A Slack workspace with two channels: #shipped and #reviews
• Your Claude Code session token (paste it in Settings > API Keys)
• GitHub and Slack integrations connected in Settings > Integrations

Step 1: Create a New Swirl and Add a Webhook Trigger

Log into Swrly and click New Swirl from the dashboard. Name it "PR Review Bot."

You will land on the visual builder — an empty canvas with a sidebar on the left showing available node types.

Drag a Trigger node onto the canvas. Click it to open the configuration panel. Set the trigger type to Webhook and copy the generated webhook URL. It will look something like:

https://swrly.com/api/v1/webhooks/trigger/wh_abc123def456

Now go to your GitHub repository. Navigate to Settings > Webhooks > Add webhook. Paste the Swrly webhook URL. Set the content type to application/json. Under "Which events would you like to trigger this webhook?", select Pull requests only. Save the webhook.

Back in Swrly, your trigger node is now listening. Every time a PR is opened, reopened, or synchronized on that repo, this workflow will fire.

Step 2: Add a Code Reviewer Agent

Drag an Agent node onto the canvas and connect it to the trigger node by drawing an edge from the trigger's output port to the agent's input port.

Click the agent node to configure it. Set the name to Code Reviewer. Now write the system prompt — this is the most important part. Here is a prompt that works well:

You are a senior code reviewer specializing in TypeScript and React
applications. When given a pull request, you must:

1. Fetch the list of changed files using the github_list_pr_files tool
2. For each changed file, fetch its content using github_get_content
3. Analyze the changes for:
   - Security vulnerabilities (SQL injection, XSS, credential exposure)
   - Performance issues (unnecessary re-renders, missing memoization, N+1 queries)
   - Error handling gaps (uncaught promises, missing try/catch blocks)
   - Code style violations (inconsistent naming, dead code, missing types)
4. Write a concise review summary

IMPORTANT: End your review with exactly one of these two lines:
- "VERDICT: APPROVED" if the code is ready to merge
- "VERDICT: NEEDS_REVISION" if changes are required

After the verdict, include a brief summary paragraph explaining your decision.

Under Agent Settings, configure:

• Max Turns: 15 — complex PRs may require multiple tool calls to fetch all files
• Accumulate Context: enabled — the agent retains context from the trigger payload, which includes the PR number and repository information
• Tools: Enable github_list_pr_files, github_get_content, and github_get_pull_request

The maxTurns setting is important here. A PR with 8 changed files requires at least 9 tool calls (one to list files, one per file). Setting it too low will cut the agent off mid-review. Setting it too high wastes tokens on edge cases. 15 is a good default for most review workflows.

Step 3: Understanding the GitHub Integration

When the Code Reviewer agent runs, it has access to GitHub MCP tools. Here is what each one does in this workflow:

github_list_pr_files — Returns the list of files changed in the PR, including the filename, status (added/modified/removed), and the number of additions and deletions. The agent uses this to know which files to inspect.

github_get_content — Fetches the full content of a specific file from the repository. The agent calls this for each changed file to read the actual code.

github_get_pull_request — Retrieves PR metadata: title, description, author, base branch, head branch, and labels. Useful for context about what the PR is supposed to do.

You do not need to write any code to use these tools. The agent calls them automatically based on its system prompt. Swrly handles authentication using your connected GitHub integration — the agent uses your GitHub token, scoped to the repositories you have authorized.

Step 4: Add a Condition Node for Branching

This is where the workflow gets interesting. Drag a Condition node onto the canvas and connect it to the Code Reviewer's output.

Click the condition node and configure the rule:

• Field: output (the agent's text output)
• Operator: contains
• Value: VERDICT: APPROVED

The condition node evaluates this rule against the Code Reviewer's output. If the output contains "VERDICT: APPROVED," the workflow follows the true branch. Otherwise, it follows the false branch.

Swrly condition nodes support six operators:

Operator	Use case
equals	Exact string match
not_equals	Inverted exact match
contains	Substring search (what we are using)
not_contains	Inverted substring search
greater_than	Numeric comparison
less_than	Numeric comparison

For this workflow, contains is the right choice. The agent's output is free-form text, and we are looking for a specific verdict string within it. Using equals would fail because the output contains much more than just the verdict line.

Step 5: Add Slack Notifications on Both Branches

Now add two Integration nodes — one for each branch of the condition.

Approved branch (true): Drag a Slack integration node and connect it to the condition's true output port. Configure it:

• Integration: Slack
• Action: slack_send_message
• Channel: #shipped
• Message template:

:white_check_mark: *PR Auto-Review: APPROVED*

*Repository:* {{trigger.repository.full_name}}
*PR:* #{{trigger.pull_request.number}} — {{trigger.pull_request.title}}
*Author:* {{trigger.pull_request.user.login}}

The automated code review found no significant issues. This PR is ready for human review and merge.

_Review powered by Swrly_

Needs revision branch (false): Drag another Slack integration node and connect it to the condition's false output port. Configure it:

• Integration: Slack
• Action: slack_send_message
• Channel: #reviews
• Message template:

:warning: *PR Auto-Review: NEEDS REVISION*

*Repository:* {{trigger.repository.full_name}}
*PR:* #{{trigger.pull_request.number}} — {{trigger.pull_request.title}}
*Author:* {{trigger.pull_request.user.login}}

*Review Summary:*
{{steps.code_reviewer.output}}

_Review powered by Swrly_

Notice the template syntax: {{trigger.*}} references the webhook payload from step 1, and {{steps.code_reviewer.output}} references the Code Reviewer agent's output. Swrly's template resolver handles the variable substitution at runtime.

Step 6: Save, Test, and Deploy

Click Save in the top bar (or press Cmd+S). Your workflow is now persisted.

Before connecting it to real PRs, test it with a single node. Click the Code Reviewer agent node, then click the Test button in the configuration panel. Swrly will run just that node with a sample payload. Verify that it fetches files, analyzes them, and produces a verdict.

You can also use Save and Run to execute the entire workflow end-to-end with a test payload. The execution overlay will light up each node as it runs — you can watch the trigger fire, the agent think, the condition evaluate, and the Slack message send, all in real time on the canvas.

Once you are satisfied, open a real PR on the connected repository. The webhook will fire, the workflow will run, and within 30-60 seconds you will see a message in the appropriate Slack channel.

Tips for Production Use

Tune maxTurns based on your codebase. If your PRs typically touch 15+ files, increase it to 20-25. Monitor token usage in the run history to find the sweet spot.

Use accumulateContext for multi-agent chains. If you add a second agent after the Code Reviewer (for example, a "Documentation Checker" that verifies README updates), enable context accumulation so the second agent can see the first agent's findings.

Add an approval node for critical repos. For production repositories, insert an Approval node before the Slack notification. A team lead reviews the AI's verdict before it is posted. This adds a human checkpoint without losing the automation benefit.

Create separate workflows for different event types. Rather than one workflow that handles opened, synchronize, and closed events, create focused workflows for each. A review workflow for opened, a re-review workflow for synchronize, and a cleanup workflow for closed.

Monitor with run history. Every execution is logged with timestamps, token usage, and full input/output for each node. If the reviewer starts producing inconsistent verdicts, check the run history to see what changed in the PR payloads.

What You Built

In about 10 minutes, you built an automated PR review pipeline that:

• Triggers on real GitHub events with no polling
• Runs an AI code reviewer with access to your repository
• Branches based on the review outcome
• Notifies the right people in the right channel

No Python scripts. No cron jobs. No infrastructure to manage. Just a visual workflow running on your own Claude Code subscription.

Try It Yourself

Sign up free at swrly.com and build your first workflow. The PR reviewer is a great starting point, but teams are using Swrly for bug triage, documentation generation, deployment pipelines, customer support routing, and much more.

---

Questions about this tutorial? Reach out at [e-mail] or open a discussion on GitHub.