The PR Review Toolkit: Five Agents Reviewing Your Code at Once

Code review is the most important quality gate in software engineering. It is also the one that almost everyone does poorly.

I don't mean badly in the moral sense. Nobody wakes up intending to do a lazy review. But you're three PRs deep on a Monday morning, you have your own feature to ship, and the diff in front of you is 400 lines across twelve files. So you skim. You catch a typo, maybe flag a missing null check, approve it, and move on. The structural problems, the silent failures, the types that allow impossible states -- those sail through because no one had time to look that carefully.

I've been on both sides of this. I've rubber-stamped PRs I should have scrutinized. I've also had bugs ship that a careful review would have caught, bugs that cost hours or days to debug in production. Pairing code review with test-driven development catches even more, but review is the safety net when tests are incomplete. The problem isn't ability. It's bandwidth. Human reviewers are generalists working under time pressure. They try to check everything and end up checking nothing thoroughly.

What if instead of one generalist reviewer skimming the whole diff, you had five specialists, each one dedicated to a single class of problem, all running at the same time?

What the PR Review Toolkit Does

The PR Review Toolkit is a Claude Code plugin that does exactly that. When you run /review-pr, it spawns five autonomous agents in parallel. Each agent has a specific mandate, a narrow focus, and instructions tailored to that one category of issue. They run simultaneously, independently, and report back with their findings.

The five agents are:

Code Reviewer -- Checks adherence to your project guidelines, style guides, and established patterns. This agent reads your CLAUDE.md files, understands your conventions, and flags deviations. It looks for anti-patterns, unnecessary complexity, code that works but doesn't fit the patterns already established in the codebase. If your project uses named exports everywhere and the PR introduces a default export, this agent catches it. If your codebase uses early returns and the PR has a deeply nested conditional, this agent flags it.

Silent Failure Hunter -- This is the star of the toolkit and the one I built the whole thing around. It specifically looks for inadequate error handling, inappropriate fallback behavior, and catch blocks that swallow errors. The bugs that don't crash your app. They just silently do the wrong thing. These are, in my experience, the hardest bugs to find in normal code review because the code looks correct. It runs. It doesn't throw. It just produces the wrong result under specific conditions, and nobody notices until a customer reports something weird three weeks later.

Type Design Analyzer -- Reviews new or modified types for encapsulation and invariant expression. It rates types on several dimensions: does the type prevent invalid states? Are fields appropriately scoped? Is validation happening at construction time? Are there states the type allows that should be impossible? This agent thinks about your types the way a domain-driven design advocate would.

PR Test Analyzer -- Reviews test coverage quality and completeness. Not the naive "does a test file exist" check, but the substantive "do these tests cover the edge cases that actually matter" analysis. It looks at the code being changed, identifies the critical paths and boundary conditions, and checks whether the tests exercise them. It identifies gaps that would let real bugs through.

Comment Analyzer -- Checks comments for accuracy, completeness, and long-term maintainability. This one catches comment rot, which is what happens when code changes but the comments describing that code don't change with it. A comment that says "this function returns null on failure" when the function now throws an exception is worse than no comment at all. It's actively misleading. This agent finds those mismatches.

Why Parallel Matters

Each agent runs independently and simultaneously. This is not a sequential pipeline where one finishes and the next starts. All five launch at the same time and execute concurrently as subagents.

The practical benefit is speed. A sequential review across all five categories would take five times longer. On a typical PR, the parallel toolkit finishes all five reviews in roughly the time it would take to do one. That matters because if the review takes too long, you won't use it. The fastest tool wins.

But speed isn't actually the most important benefit of parallelism. Specialization is.

A generalist reviewer tries to catch everything. Style issues, error handling, type safety, test coverage, comment accuracy -- all in one pass. The problem is that each of those categories requires a different mental model. When you're thinking about error handling, you're tracing failure paths. When you're thinking about type design, you're reasoning about invariants and valid states. When you're evaluating test coverage, you're thinking about edge cases and boundary conditions. Switching between these modes in a single pass means you're doing each one shallowly.

Specialists go deep. The Silent Failure Hunter doesn't care about your variable names. The Type Design Analyzer doesn't care about your test structure. Each agent brings its full attention to one category of issue and finds things that a generalist pass would miss. This is the same principle behind specialized roles on engineering teams. Your security reviewer catches vulnerabilities that your feature reviewer doesn't because they're looking for different things.

Five narrow agents catch more than one broad agent. I've tested this extensively. The parallel toolkit consistently surfaces issues that a single comprehensive review prompt misses, even when given the same total context and time.

What Each Agent Actually Catches

Theory is nice. Let me show you what these agents actually flag.

Silent Failure Hunter

This agent is the reason the toolkit exists. It catches patterns like:

Copytry {
  const result = await fetchUserData(userId);
  return result;
} catch (e) {
  return null;
}

That catch block swallows the error completely. The caller gets null and has no idea why. Was it a network error? An auth failure? A malformed response? The information is gone. The app continues running with null data, which either causes a confusing error somewhere downstream or silently shows the user wrong information.

It also catches fallback behavior that masks real problems:

Copyconst config = loadConfig() || DEFAULT_CONFIG;

If loadConfig fails because the config file is missing or corrupted, you silently fall back to defaults. In development, this looks fine. In production, your service is running with default configuration and nobody knows. The Silent Failure Hunter flags this pattern and asks: should this be an error instead of a silent fallback?

Default values that hide configuration problems:

Copyconst timeout = process.env.REQUEST_TIMEOUT
  ? parseInt(process.env.REQUEST_TIMEOUT)
  : 5000;

If REQUEST_TIMEOUT is set to "abc", parseInt returns NaN, the ternary evaluates to truthy (because NaN is the result of a successful parse, not undefined), and you get NaN as your timeout. The fallback to 5000 never triggers. The agent catches this because it's looking specifically for these kinds of silent mishandling patterns.

These bugs are insidious because they pass every test that checks the happy path. The code works. The tests pass. The app runs. It just does the wrong thing under specific conditions that nobody thought to test.

Type Design Analyzer

This agent thinks about types differently than most developers do during a quick review. It catches structural problems like:

Copyinterface ApiResponse {
  status: "loading" | "success" | "error";
  data: UserData | null;
  error: string | null;
}

This type allows impossible states. You can have status: "loading" with data: someUserData. You can have status: "success" with error: "something went wrong". The type doesn't encode the invariants that should hold. The analyzer would suggest a discriminated union instead:

Copytype ApiResponse =
  | { status: "loading" }
  | { status: "success"; data: UserData }
  | { status: "error"; error: string };

Now invalid states are unrepresentable. The type system enforces your invariants instead of relying on developers to remember them.

It also catches types with public fields that should be private, missing validation at construction time, and overly permissive types where a narrower type would prevent bugs. If you define a function parameter as string when it should be a branded type or a specific union of known values, this agent will flag it.

Code Reviewer

The Code Reviewer is the most straightforward agent, but it benefits enormously from reading your CLAUDE.md. It doesn't just check generic best practices. It checks your project's specific conventions.

If your CLAUDE.md says "prefer composition over inheritance" and the PR introduces a class hierarchy, this agent flags it. If your project uses a specific error handling pattern and the PR introduces a different one, it catches the inconsistency. If the PR adds a utility function that duplicates logic already existing elsewhere in the codebase, it finds the duplication.

This is the agent that would catch you if you submitted code written with a different project's conventions in mind. It enforces consistency across the codebase in a way that's tedious for humans but trivial for an agent that can read every relevant file in seconds.

PR Test Analyzer

The Test Analyzer goes beyond "tests exist" to "tests are sufficient." It reads the production code changes, identifies the critical decision points and boundary conditions, and then checks whether the test suite exercises them.

A common finding: tests that only cover the happy path. The feature works when given valid input. But what about empty input? Null input? Input at the exact boundary of a range? The test analyzer identifies these gaps specifically by analyzing the code paths in the changed files.

It also catches tests that test implementation details instead of behavior. Tests that break every time you refactor without any actual bug are a maintenance burden, not a safety net. The analyzer flags tests that are tightly coupled to internal implementation when they should be asserting on external behavior.

Comment Analyzer

Comment rot is one of those things everybody knows is a problem and nobody does anything about. During a normal review, you read the comments alongside the code and they make sense. But the Comment Analyzer specifically cross-references comments against the current code behavior.

It catches function docstrings that describe parameters that no longer exist. It finds TODO comments that reference tickets that were completed months ago. It flags comments that say "this is temporary" on code that has been in production for a year. And most importantly, it catches comments that describe behavior that has since changed -- the most dangerous kind of wrong comment, because a developer reading it will trust the comment over their own reading of the code.

The Commit Commands Complement

The review toolkit is one part of a broader workflow. Once you've reviewed your PR and addressed the issues, the /commit-push-pr command handles the git mechanics: stage changes, create a commit with a well-formatted message, push to the remote, and open a pull request. No context switching to a git GUI. No copying branch names. One command.

There's also clean_gone for housekeeping. After PRs are merged, you accumulate stale local branches that track remote branches that no longer exist. clean_gone removes them. Small quality-of-life thing, but it keeps your local repo clean.

The full pipeline becomes: write code, run /review-pr, fix the issues the agents found, run /commit-push-pr, done. The entire post-coding workflow is two commands. I walk through this exact pipeline as part of my end-to-end feature workflow.

How It Compares to Human Review

I want to be clear about what this replaces and what it doesn't.

The PR Review Toolkit does not replace human code review. It replaces the mechanical parts of human code review. The parts where a reviewer is checking for consistent error handling, scanning for missing tests, verifying that comments match code, and ensuring types are well-designed. These are important checks. They're also tedious, repetitive, and exactly the kind of work that humans do inconsistently under time pressure.

What human reviewers are genuinely good at, better than any agent, is evaluating architecture and design decisions. Should this feature be a new service or part of the existing one? Is this the right abstraction boundary? Does this approach scale for what we're planning next quarter? These require business context, historical knowledge, and judgment that agents don't have.

The toolkit handles the first pass. It catches the mechanical issues, the silent failures, the type design problems, the test gaps, the stale comments. The human reviewer then sees a PR that's already been cleaned of those issues and can focus entirely on the questions that require human judgment. The quality of the human review goes up because the human isn't spending mental energy on things a machine could have caught.

I've found that running the toolkit before requesting human review consistently reduces review round-trips. Fewer "you forgot to handle the error case" comments. Fewer "this test doesn't cover the edge case" flags. The human reviewer gets a cleaner PR, gives better feedback, and the whole process is faster.

Setting It Up

Install the pr-review-toolkit plugin. That's it. The agents come pre-configured with their mandates and instructions. You don't need to set up five separate things or write custom prompts for each reviewer. You can see how it fits alongside my other 18 plugins in my exact setup walkthrough.

If you want to use individual agents directly, you can. Each agent is also available as a standalone command. If you're working on a type-heavy change and only want the Type Design Analyzer, you can invoke just that one. If you're debugging a production issue and want to specifically hunt for silent failures, you can run only the Silent Failure Hunter. The full /review-pr command is just the convenience of running all five at once.

The agents respect your CLAUDE.md configuration. Your project conventions, your coding standards, your tech stack constraints -- all of it feeds into the review. This means the toolkit is immediately useful on any project that has a CLAUDE.md file, which if you've been following this series, should be every project.

The Real Point

Here's what I actually care about. The best code review process is one that catches real bugs. Not one that nitpicks indentation, not one that enforces a style guide that a linter should handle, not one that generates twenty comments about variable naming while a silent failure sails through untouched.

Five specialized agents reviewing in parallel catches more real issues in two minutes than most human reviews catch in twenty. That's not because humans are bad at review. It's because humans are trying to do five different things at once while also thinking about lunch and the meeting in thirty minutes and the three other PRs in their queue.

The agents don't get tired. They don't get distracted. They don't rubber-stamp a PR because they reviewed four others this morning and their attention is shot. They run the same thorough, specialized analysis every single time, on every single PR, with the same focus.

That consistency is the real value. Not any single brilliant catch, though those happen. The value is that the floor of your review quality goes up. The worst review is no longer a five-second skim and an approval. The worst review is five agents running independently and reporting back, even if the human reviewer is having a bad day.

Use it. Run /review-pr before you push. Let the machines do what they're good at so the humans can do what they're good at. That's the whole idea.