Skip to main content

AI Code Review

Type: ExplanationCreated: Team: Platform
draft

What it is

Claude PR Reviewer is an in-house tool the team runs to give every pull request an automated first-pass review. It watches for PRs that are waiting on review, reads the change against the full codebase, and posts what it finds as review comments on the PR — the same kind of comments a human reviewer leaves.

It doesn't approve or merge anything, and it doesn't replace a human reviewer. It's an early second set of eyes that catches the common, easy-to-miss issues before a person looks at the change. It runs on a developer's machine and uses the gh command-line tool to talk to GitHub and the Claude command-line tool to do the actual reviewing.

How a review happens

At a high level, each review runs through the same steps:

  1. It picks up a PR that's waiting for review from the team's PR dashboard.
  2. It fetches the PR's diff and checks out its branch from a local clone of the repo — so the reviewer can read the surrounding code, not just the lines in the diff.
  3. It loads a shared set of review rules plus the review criteria for that repo (see below), and asks Claude to review the change in two passes: a first pass, then a second pass that looks specifically for anything the first one missed.
  4. It keeps only the findings that land on lines the PR actually changed, and drops anything it already posted in an earlier review of the same PR.
  5. It posts a short summary plus inline comments on the PR.

How findings are labelled

Every finding carries one of three severities, so it's clear what needs acting on:

  • 🔴 Important — should be fixed before merging (logic bugs, security holes, data-loss risks).
  • 🟡 Suggestion — worth considering (unhandled edge cases, performance, error handling gaps).
  • 🟣 Nit — minor or uncertain (naming, small simplifications). The reviewer flags things it's unsure about as nits and lets you decide.

Review criteria by repo

On top of the shared review rules that apply to every PR, the reviewer loads criteria written for the specific stack it's looking at, picked from the repo the PR belongs to:

RepoChange areaCriteria page
skapp (core monorepo)frontend/ changesCore frontend
skapp (core monorepo)backend/ changesCore backend
Core enterprise submodulesfrontend / backendFold into Core frontend / Core backend
skapp-pmfrontend/ changesProject management frontend
skapp-pmbackend/ changesProject management backend
skapp-migrationsdatabase migrationsMigrations service
note

The tool also recognises the skapp-ai and skapp-ui repos, but review criteria for those two haven't been written yet — PRs there fall back to no specific guidelines until their pages exist.

Using these before you raise a PR

These criteria pages are just as useful before review as during it. Before you open a PR in one of these repos, skim its page and run through the checklist against your own change — most of what the reviewer flags is something you can catch and fix yourself first. It's also a quick way to learn what "good" looks like in a part of the codebase you haven't worked in before.