FiretrailDocs
Open app

Rework

You know the PR. It adds a feature, quietly bumps a timeout, fixes a bug it ran into on the way, and touches 40 files. Firetrail's analysis says what's wrong with it — three intents, an undisclosed config change, an N+1 the review team spotted. What it didn't do, until now, is tell you what the good version of that PR looks like.

Rework does. Firetrail reads its own analysis of the PR and writes a plan: an ordered chain of smaller pull requests, each shipping one thing, each fixing the findings that belong to it. Then your coding agent (Claude Code, Cursor, Codex, VS Code or any MCP client) carries the plan out in your repository through the Firetrail MCP and reports the new PRs back.

Rework is a Business feature.

Starting a rework

You don't need to open Firetrail. Once a PR has been analyzed, its Firetrail comment on GitHub ends with the sentence to say to your coding agent:

🔧 Rework this PR the Firetrail way — in your coding agent (Claude Code or any MCP client), say rework PR #123 with Firetrail

Say it, and the agent asks Firetrail for the plan — which is already there: on Business, Firetrail writes the plan for every analyzed PR right after the analysis, so the comment says Rework plan ready and the agent starts immediately. (For an analysis that predates Rework, the plan is written on the spot — a minute or two.)

The PR's Rework tab in Firetrail is where you steer it before you run it: the split is drawn as a flow — the original PR on top, each proposed PR hanging off it, chained where one builds on another. Click a PR to see exactly what it carries and to skip it; the agent leaves skipped steps out. And if you'd rather it went differently — "keep the API and the UI in one PR, the rest is perfect" — write that in Steer the plan and Firetrail re-plans in that direction, keeping everything you didn't question. When the plan has several PRs you choose what the note is about: the whole plan, or one of the PRs. Every steer is recorded in the diagram: the card a steer changed grows a new version underneath it, with the steer on the line between the two — who said what, when — so a team can see how the plan got here at a glance. Cards the steer didn't touch stay as they were. The latest steer can be rolled back (the plan it replaced comes straight back, no waiting).

Not every rework is a split. When the PR should stay one PR but the findings need fixing, the plan shows a single card — Same PR, reworked — that spells out exactly what changes versus the original.

Open a PR's card and you'll find Features included: the checklist of what that PR ships. Switch anything off and the agent won't implement it. You can also add your own — "remember to add the empty state to the UI" — and Firetrail checks it against what the other planned PRs implement, so two PRs never step on each other's toes (an overlap shows a warning; you decide). One honest rule: Firetrail itself never invents features your PR didn't contain — so anything you add is labeled with your name, and the agent asks you to confirm those extras explicitly before implementing them. They were your idea, not the original PR's.

What a plan contains

Every plan has:

  • A summary in plain words — what the PR is really doing and how it splits.
  • The map — "How Firetrail split it": one band of every file the PR touches, cut into the pieces the plan proposes, colored by the kind of file in each piece and numbered with the PR it becomes, plus the notes that follow from it (which PR waits for which, a migration that travels alone, files no proposed PR named). Under it, in Firetrail's own words, what it deliberately left out — an undisclosed change the description never mentioned, for example, either becomes its own step or is excluded, and the notes say which.
  • Steps, in order. Each step has:
    • the intent — the one thing that PR ships;
    • the files to carry over from the original PR (Firetrail only lists files that are actually in the PR; a file the step must create, like a missing test, is marked separately);
    • the findings it fixes, each traced back to the classifier or reviewer that raised it;
    • which Future Debug Cost drivers it removes and how many points;
    • acceptance criteria written for this change — things you can check by reading the PR or running a command, never "code is clean";
    • a branch name, and whether the step builds on the previous one (chained branches) or stands alone.

Firetrail plans from its analysis, not from the diff. It doesn't rewrite your code — the plan is about partitioning the change the author already made and fixing what the analysis flagged. If the PR is already one clean intent with nothing worth splitting, the plan says so: No rework needed, with the reason.

If the analysis was partial (a very large PR sampled down to its highest-churn files), the plan says that too. It only covers what was analyzed.

Running the plan from your coding agent

Firetrail never writes to your repository. The plan is carried out by your own coding agent — Claude Code, Cursor, Codex, VS Code or any MCP client — talking to Firetrail through the Firetrail MCP. Connecting takes two steps, once per person:

  1. In Firetrail, open MCP from the top bar and create a personal token.
  2. Add the Firetrail server to your agent with the snippet the page shows for it.

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

Rework PR 123 with Firetrail

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

The agent fetches the plan, shows it to you, and asks you to confirm. Only then does it start: for each step it creates the branch, brings over that step's files from the original PR, fixes the findings (pulling the full evidence from Firetrail when it needs it), runs the tests that cover the change, and opens a draft PR with a body that explains what it ships, which findings it addresses, how to review it, how to test it, and what to merge first. When every step is open it reports the new PRs back to Firetrail.

Two things happen automatically before the plan appears. If the PR hasn't been analyzed yet, the agent asks Firetrail to analyze it and waits (one to three minutes). And if the PR has new commits since the last analysis, Firetrail notices — the agent sends the commit it has locally — and re-analyzes first, so the plan never describes an older version of the change. The Rework tab shows the same warning when a plan has gone stale.

When you run the rework, Firetrail also renders the plan as a branded page and hosts it at its own link, which the agent hands you — the same layout every time, served by Firetrail itself (no dependency on an outside service), so you can read or share the plan comfortably. Either way, nothing runs until you confirm the plan in the terminal.

Some rules the agent follows, by construction:

  • It never modifies, rebases, force-pushes or closes the original PR's branch. It only creates new branches.
  • Every PR it opens is a draft. It never merges.
  • It asks before writing any code.

What you see afterwards

On the original PR's Firetrail comment on GitHub, a line appears: Reworked the Firetrail way — split into #124 · #125 · #126. Each new PR is a normal PR, so Firetrail analyzes it on its own — you can compare the Future Debug Cost of the parts against the original.

Team-wide on Claude Code, you can check a .mcp.json into the repository so every developer gets the Firetrail server the moment they open it (the Firetrail MCP page shows the file; each person exports their own token as FIRETRAIL_TOKEN).

Cost and limits

Building a plan is one AI call over the existing analysis — comparable to a single classifier run, once per analyzed PR on Business (a re-plan with a new direction is another call). The code work runs in each developer's own coding agent, on their own account, so Firetrail doesn't meter it.

The MCP tools answer with a plain message when something's off: the repository isn't connected to a project you belong to, the PR hasn't been analyzed yet, or the organization isn't on Business. Personal tokens can be revoked at any time from the Firetrail MCP page; a revoked token stops working immediately.