The review team

Most code review has a blind-spot problem: your reviewer is great at some things. The backend expert skims your CSS. The frontend expert approves your migration. Nobody on the team has deep accessibility instincts, so that lens just… never gets applied.

The review team gives every pull request a whole panel of reviewers at once, each with a different specialty. There are ten of them. Your plan decides how many review each pull request, and you choose which ones for each project. Each one reads the PR independently, through their own lens, and gives an honest opinion. Their verdicts are advisory — they never change the Future Debug Cost and never block a merge. Think of them as extra sets of experienced eyes, not gates.

Meet the reviewers

Bob — Senior Backend Engineer. Design and correctness on the server side: clear responsibilities, sane data access, reliability, and whether the thing will actually behave in production.
Jim — Senior Frontend Engineer. UI implementation and component design, the UX states everyone forgets (loading, empty, error), and frontend performance.
Rick — Senior Security Engineer. Secrets, authentication and authorization, tenant isolation, unsafe input and output, and how the change could be abused.
Garick — Senior Database Engineer. Schema design, constraints, indexes, migration safety, and data integrity.
Steve — Accessibility Specialist. Keyboard access, focus handling, semantics and ARIA, contrast — whether everyone can actually use what you built.
Tom — Professor of Software Heuristics. The design-principles reviewer: the timeless rules of maintainable software, applied to your diff.
Sarah — Senior SRE / Platform Engineer. What happens between merge and 3 a.m.: configuration and environment variables, deploy safety and rollback, failure modes, observability, scaling, and the assumptions the change makes about your infrastructure.
Mike — Senior QA / Test Engineer. Whether the behavior is actually proven: missing test cases, regression risk, boundary conditions, race conditions, and whether the important flows have integration or end-to-end coverage.
Priya — Privacy & Compliance Engineer. What happens to people's data: personal information you didn't need to collect, consent for analytics, GDPR/CCPA obligations, retention and deletion, what gets shared with third parties, and sensitive values ending up in logs.
Alex — Performance Engineer. The cost of the change end to end: bundle size, N+1 calls, unnecessary re-renders, expensive queries, memory leaks, latency, and caching.

Each reviewer carries a deep private checklist for their specialty, but they only speak up about what your PR actually triggers — you get findings, not a lecture.

They review the change, not just the code

Each reviewer looks at the pull request the way a senior colleague would: the code, and also how the change is put together. A dependency pin bundled with a feature, a frontend and its backend shipped in one PR, a refactor mixed with a behavior change, or risky logic without tests are concerns in every specialty, even when each piece is well written — because they make the review harder now and the debugging harder later. A well-written PR that is doing too much at once gets a "meh" at best, and the reviewer says how they would split it.

Before the team starts, Firetrail's structural checks have already run, and each reviewer is handed what they found as plain facts ("the Gemfile pins a dependency in the same PR as the feature") to weigh in their own specialty.

Verdicts

Every reviewer lands on one of four verdicts, and the verdict follows from their findings — a finding is something they would ask you to change:

✅ Yes — happy to see this merge. Only when every finding is a minor or a note, or there are none.
🤔 Meh — it'll work, but they have a real reservation (a concern finding) worth reading.
❌ No — they found something they'd want fixed first (a major finding).
➖ N/A — the PR doesn't touch their area (Steve won't grade a backend-only migration).

A reviewer can be stricter than their findings, never looser: you will not see a "yes" sitting next to a concern.

Satisfaction

Each opinion also carries a satisfaction number, 0–100: how happy the reviewer is with the change from their point of view. It sits inside the band of the verdict — a yes is 75 or above, a meh between 45 and 74, a no below 45 — so the number and the badge can't disagree. Roughly: 90+ nothing they'd change; 75–89 nits only; 60–74 one thing they'd ask for; 45–59 real reservations; below 45 they wouldn't approve as-is. Anything below 90 comes with the findings that explain it. N/A has no number.

Why the reviewers and the score can differ

The reviewers rate the code as written, one angle each, and their verdicts are never added together. Future Debug Cost rates how the change is packaged — bundled, disclosed, tested — and it does add up: every driver that fires is worth 5 to 25 points, so a PR with five moderate patterns at once lands at Critical even though no single pattern is alarming. That is why the two can sit a couple of bands apart without either being wrong:

Happy reviewers next to a Critical score usually means the cost is in how the PR is bundled; splitting it would bring the two into line.
A row of "meh"s next to a Critical score means nobody found an alarm, but the drivers stacked. Each reviewer saw one thing they'd ask for; the score saw all of them at once.
A clean score next to a "no" means the packaging is fine but a reviewer found something in the code itself. Read their findings before the score.

The PR comment and the PR page say which case you're looking at, in one line under the team, and whenever the two point in different directions the comment lists the drivers that fired, with their points, right under that line.

While the team is reading, each card shows a pulsing "reviewing…" state; verdicts drop in as reviewers finish.

Reading a full review

Click any reviewer's card to open their complete review:

Satisfaction — how happy they are with the change itself (0–100%). An N/A reviewer shows a dash over a gray bar instead — they have no opinion to score, so there's no number to read into.
Confidence — how sure they are of their own verdict. A low-confidence "no" is a nudge; a high-confidence "no" deserves your attention.
A headline and an overall summary — their take in a couple of sentences.
Findings, sorted by severity: major (they'd want it fixed before merge), concern (a real reservation, to fix now or right after merge), minor (worth fixing, but they'd still approve without it) or note (a nit). Each finding names the principle behind it, explains the issue in plain language, and points at the exact files that triggered it.

A practical way to use the panel: skim the verdicts for the overall temperature, then open whichever reviewer's specialty matches what the PR actually changes. If your PR touches a migration and Garick says ❌, read Garick.

The Code review tab

The Code review tab on the PR page puts every finding from every reviewer in one list, the way review comments read on a pull request. The most serious come first, and you can filter the list to one severity. Each finding shows who raised it and reads the same way every time:

The title says what should change, and the line under it is the rule behind the finding.
What's the issue — what the diff does, where, and when it goes wrong.
Why it matters — why this is important for your codebase and the people who use it.
If it isn't fixed — what happens if the PR ships as it is.
Possible solution — the change the reviewer would make, specific enough to start on.
Affected files — every file involved, with the reason it matters.

A review that ran before reviewers wrote findings this way has only the title, the rule and the issue. The tab says how many findings are like that, and re-running the analysis brings the rest.

Reviewing an older PR

If a PR was analyzed before its project had reviewers (or before an upgrade), its page shows a "👥 Run team review" button. It runs the reviewers in the project's lineup on the existing analysis — quick, and no full re-analysis needed. A project without a lineup shows Choose your Judges there instead.

Choosing your lineup

Your lineup is the set of reviewers who review a project's pull requests. Each plan has a number of slots, which is how many reviewers review each pull request, and any reviewer can take a slot.

When you connect a repository, Firetrail asks you to choose the project's reviewers before anything else. Pick one reviewer per slot and click Lock in lineup, or click Skip and use the default lineup. Skipping locks in the first reviewers in the order listed above: Bob on Free; Bob, Jim and Rick on Starter; Bob, Jim, Rick, Garick, Steve and Tom on Pro. Business has a slot for every reviewer, so it skips this step.

A project without a lineup gets no reviewers. Firetrail doesn't choose for you: until an owner or manager locks in a lineup, or the default lineup, no reviewer reviews that project's pull requests. The project's Pull requests page and each pull request's Team tab say so and link to the lineup. That includes projects connected before lineups existed.

To change the lineup later, open Project settings in the project's side menu and find Choose your Judges. Click a reviewer to put them in a free slot, or click someone already in the lineup to take them out. When every slot is taken, take someone out first; on a one-slot plan, clicking another reviewer swaps them in. Lock in lineup saves it once every slot is filled. Organization owners and managers can change the lineup; everyone else on the project can see it.

A few examples of why you'd change it: a repository with no database doesn't need Garick, a mobile backend might want Sarah watching deploy safety instead, and a team handling health data might keep Priya in the lineup on every plan.

The change applies to the next analysis. Pull requests already reviewed keep the reviewers they had, and the ones who weren't in the lineup show as on the bench.

What's included per plan

Free has one slot. A backend-heavy team might pick Rick for the security lens it lacks.
Starter has three slots.
Pro has six slots.
Business has a slot for all ten, so every reviewer reviews every pull request and there's nothing to choose.

When a plan changes, a project's lineup adjusts on its own. An upgrade fills the new slots with the next reviewers in the order above, and a downgrade keeps the reviewers you picked first. A project that never had a lineup still needs one after moving off Business.

See Plans & billing.