FiretrailDocs
Open app

Review Brief

Reviewing someone else's pull request is mostly reconstruction. You read the diff to work out which endpoints changed and how their contracts moved, which tables the migration touches, what's a real feature versus a mechanical refactor, and which few hunks actually matter. Firetrail already worked most of that out when it analyzed the PR. A Review Brief puts it on one page.

A brief is a single, self-contained page you open before you approve a PR. It lays out:

  • The endpoints the PR adds or changes, each expandable to its full contract — the parameters, and a real request and response (a modified endpoint shows before and after).
  • The schema diff, one table per database table, listing every column added, removed, renamed or retyped.
  • The change mix — how much of the PR is a new feature, a refactor, a fix, or tests — as one bar.
  • Intent drift — anything the PR does that its description didn't mention, with the evidence and a short theory of why it's there.
  • The review team's findings and the Future Debug Cost, from the analysis.
  • Patch coverage, when your plan produces it.
  • The key changes per file — the load-bearing hunks, not every line.
  • A wireframe of every screen the PR adds or changes — drawn from the diff, not screenshotted.
  • Any flow, handshake, pipeline or hierarchy in the change drawn as a diagram — a sequence between actors, a graph of states or stages, or a tree — with the numbered steps written out under it, so every arrow can be checked against a sentence.

It's built to be scanned first and zoomed into on demand: everything is collapsed except the flows and the most important endpoint, and you expand a single row when you want the detail.

How it's built

A brief is a mix of two things. Firetrail's analysis is the ground truth for the change mix, the intent drift and the findings — that's the part a local tool can't recompute. The rest — the endpoints, the schema, the key changes and the wireframes — is written from the diff, and there are two ways to write it.

Automatically (Business). After every analysis, Firetrail writes the brief itself and links it from the PR's GitHub comment — no agent, nothing to ask for. It writes from exactly what the analysis already had in front of it: the diff, and the regions of your repository that Firetrail's repository index picked for this change (the callers of what changed, the definitions the new code calls, the routes and schema it must respect). Nothing else is read; no copy of the repository is made for a brief. The comment says "writing" while it works and links the page when it's ready, or says in plain words why there is none. The page foot says what it was written from — the diff and how many regions of the index, or the diff alone when the index wasn't available — so you know how far to trust an inferred.

From a checkout (every plan). Your own coding agent (Claude Code, Cursor, Codex, VS Code or any MCP client) reads the diff and the code around it, draws the UI as wireframes from that same diff, and hands all of that to Firetrail. It has the whole checkout, so it looks further than the index's regions; on Business, asking for one simply replaces the automatic brief on that PR (same link). The agent never runs your app or takes screenshots — inferring the screens from the changed code is what keeps a brief fast.

Either way, Firetrail merges the fragments with the analysis, renders the branded page itself, and hosts it at its own link — so every brief looks the same and the page doesn't depend on an outside service. Firetrail itself never reads your working tree.

Asking for one from your agent

Connecting your agent to Firetrail takes two steps, once per person (see Firetrail MCP, or MCP in the app's top bar): create a personal token, then add the Firetrail server to your agent with the snippet the page shows for it.

Then, in a checkout of the repository, ask the agent:

Give me a review brief for PR 123 with Firetrail

(In Claude Code the slash command /mcp__firetrail__review_brief 123 is the exact equivalent — that's Claude Code's naming for anything an MCP server provides; both do the same thing.)

The agent asks Firetrail for the analysis, reads the diff for the parts Firetrail can't see, draws the screens as wireframes, and hands the pieces to Firetrail — which renders and hosts the brief and returns the link. If the PR hasn't been analyzed yet — or has new commits since the last analysis — Firetrail analyzes it first (one to three minutes) and the brief waits for it.

Availability

Review Brief is on every plan through your agent, and automatic on Business. A brief is your analysis, surfaced, so it's as detailed as your plan's analysis is: a Free workspace's brief carries the core classifiers; Pro adds intent drift and patch coverage; Business adds the full ten-person review team. Through the MCP, the code-reading and the wireframing run in each developer's own coding agent, on their own account, so Firetrail doesn't meter that part. The automatic brief is one model call per analyzed PR on Firetrail's side, included in Business — it's not metered separately and it doesn't count against your PR allowance.