The PR Review Skill: How We Check Every Change Before It Ships

Every feature or fix we ship on a client app goes through one review first. We call it pr-review. It is part of the review system we describe in How We Review AI-Written Code. This post explains that one check in depth: first in plain English for founders, then in full detail for developers.

The Plain-English Version (for Founders)

Think of each change to your app as a delivery. Before it goes on the shelf, someone opens the box and checks what’s inside.

The PR review is that check. It only looks at what changed, so it’s fast enough to run every time. It does four jobs:

1. It looks for bugs. Does the change do what it should? What happens with empty input, a slow network, or two people clicking at once? Did it break something that used to work?

2. It checks the change against our rules. We hold every app to 13 architecture rules. For example: “a customer can only change their own data.” A change can work today and still break a rule that costs you later.

3. It runs a few focused checks. Are errors reported, or quietly hidden? Is the new behavior tested? If the database changed, is its design still sound?

4. It gives one clear answer. Ready to ship, not ready, or ready with fixes. Problems are ranked from most to least serious, each with the exact file and the fix. Missing tests get written, not just listed.

Why it matters: a bug caught before it ships costs minutes. The same bug found by a customer costs trust, and usually days.

The Technical Version (for Developers)

Scope

Diff only. By default it reviews main...HEAD. With no commits yet, it reviews staged and unstaged changes. For a whole-codebase sweep, use the weekly review skill instead.

It first lists the changed files. That list decides which conditional passes run.

Step 1: Conditional audits

Source: custom.

These run only when the diff makes them relevant:

• Schema audit. Migrations or schema.dbml changed: missing constraints, normalization issues, business-rule gaps.
• Domain-model audit. Same trigger: aggregate boundaries, naming, logic leaking into the wrong layer.
• Dead code and drift. Files deleted or renamed, or shared lib/ touched: unused exports, stale shims, old and new code paths living side by side.

Step 2: Bug pass

Source: adapted from the requesting-code-review skill in superpowers (MIT).

A fresh subagent reviews the diff for bugs, regressions, edge cases, broken behavior, and missing tests. It has no memory of the session that wrote the code, so it reviews what’s there, not what was meant.

Step 3: Architecture pass

Source: custom.

A second subagent checks the diff against all 13 rules from How to Stop AI from Vibe-Coding Your Next.js App into a Mess. Routes only coordinate. Validate at every boundary. Every UPDATE/DELETE carries a user_id predicate. Read-then-write runs in a transaction with FOR UPDATE.

The two passes run one after the other, never merged into one prompt. A reviewer asked to find everything tends to find one problem and stop.

Step 4: Specialist passes

Source: custom, except Simplify, which is Claude Code’s built-in /simplify.

Run in parallel:

Pass	Runs when	Looks for
Error contracts	Always	Silent catch blocks, swallowed failures, inconsistent error shapes
Test gaps	Always	Untested behavior, tests that check the wrong thing
TypeScript	New types or interfaces	Unsafe casts, weak types, any at boundaries
Simplify	Always, last	Duplication, missed reuse, code that can be simpler

Step 5: One report

Source: custom.

Everything merges into code-review/{DATE}/full-review.md: bug findings, architecture findings, specialist findings, then a combined assessment.

Ready to merge? Yes | No | With fixes

Critical   — all critical findings from every pass
Important  — all important findings
Minor      — all minor findings

Patterns   — the same issue seen more than once, with a systemic fix

The Patterns section matters most over time. If the same mistake shows up in three places, the fix is a rule or a checklist change, not three separate patches.

Step 6: Test fixes

Source: custom.

If the review found test gaps, the test-fix skill writes the missing tests. Skipped when there are no gaps and all tests pass.

Step 7: Short summary

Source: custom.

You get the verdict, the critical and important items, and the tests that were added. The full report stays in the file.

What’s custom, what’s built in, and why

Claude Code ships with its own /code-review. So why build our own? Because a review only finds what it knows to look for. Some checks are the same for every codebase. Others depend on our rules and on mistakes we’ve seen AI make again and again. We don’t build custom where the default already does the job.

Part	Source	Why
Simplify pass	Built into Claude Code (/simplify), used as is	Spotting duplication and missed reuse is the same job in every codebase. The built-in one does it well and improves with each release.
Bug pass	Adapted from the requesting-code-review skill in superpowers (MIT)	Bug hunting is mostly generic, and a solid open version already existed. We changed it to run as a fresh subagent and feed one merged report.
Architecture pass and the 13 rules	Custom	No general reviewer knows your rules. The built-in review won’t flag a route doing database work, or an UPDATE with no user_id predicate, unless it causes an obvious bug.
Error-contract, test-gap, TypeScript, schema, domain-model, and dead-code passes	Custom	Each targets a failure we kept finding in AI-written code: swallowed errors, tests that assert the wrong thing, any at boundaries, missing constraints, stale shims.
Test fixes	Custom	General reviews list missing tests. This one writes them, so the gap closes before merge.
Orchestration, merged report, verdict	Custom	Which pass runs when, how findings merge, and the merge verdict are what turn separate tools into one process.

Our rule of thumb: use the default when the job is the same for every codebase. Go custom when the check depends on your rules or on a failure that keeps coming back.

pr-review vs Claude’s built-in /code-review

	/code-review	pr-review
Finds correctness bugs	Yes	Yes
Checks your architecture rules	No	Yes, all 13
Error, test, and type specialists	No	Yes
Writes missing tests	No	Yes
Flags repeated patterns	No	Yes

Use the built-in one for a quick bug check on a small change. Use pr-review before you merge anything that matters.

Where a senior developer steps in

pr-review is the first sweep, not the last word. For security-sensitive code (auth, payments, permissions, personal data, anything that deletes or moves data), a senior developer on our team reads the code by hand. How much depends on how sensitive the code is and what stage the app is at.

Stage	What gets read by hand
MVP	pr-review runs on every change. Hand reads are rare: speed matters more, and much of this code may be thrown out.
Pre-launch	A senior developer reads all security-sensitive code line by line before real users arrive.
In production, making money	Every change to security-sensitive code is read by a senior developer before merge. Other changes get pr-review plus spot checks, weighted by how much they matter.

The tools find candidates. A senior developer reads the code and decides.

---

Get the Kit Free

pr-review is part of our free Claude Code plugin, along with the weekly review, the 13 rules, and every check they call. In Claude Code, run:

/plugin marketplace add kbventures/ingenix-code-review
/plugin install code-review-kit@ingenix

Then run /code-review-kit:pr-review after your next change. Read the skill itself on GitHub.

---

Want This Run on Your App?

If your app was built fast with AI and changes ship without a real check, we’ll set up the review on your repo and walk you through the first report: what’s broken, what’s risky, and the fixes that matter most.

Book a Free Discovery Call