Code Walkthrough

The Code Walkthrough is where you read the change itself. It shows the changed code one file at a time, and puts each explanation on the lines it is about.

Files and waypoints

The walkthrough’s header states its coverage, such as All 14 changed files or 12 of 14 changed files, so you can see when it leaves files out.

Each file shows its path, how many waypoints it has with the findings and core changes among them, an Open on link to the forge, and a File reviewed toggle. Then comes its code, with unchanged stretches folded away.

A waypoint marks a block of changed code. Flight Plan gives each changed block its own waypoint, and nests the steps inside a block when there are two or more. A waypoint’s card shows:

• its marks: its most severe finding, Core change, and Spotlight with the topics it matches,
• its title, its lines and its position, such as 3 of 12,
• your agent’s explanation: what the code does now and why it changed.

Expand (R) opens the waypoint to read all of it, with its findings.

Until your agent explains a waypoint, its card shows Flight Plan’s hint, such as “Changes a hook.”, and says the agent hasn’t explained it or checked it for issues yet. Its mark beside the code is a grey dashed ring. Ask Claude to write an explanation (G) asks your agent for that waypoint. The chevron joined to it opens a menu with Ask Claude to write the explanation for the whole block (Ctrl+G), for every waypoint of the block it sits in. See Explaining a review.

Flight Plan picks the files, the blocks, the lines and the order. Your agent writes the titles, the explanations, the core change notes and the findings.

Spotlight and Core change

• Spotlight marks a waypoint whose code is one of the topics you care about, such as a page or a database read or write. Flight Plan sets it from the spotlight of your review configuration, and draws rays around the waypoint’s mark.
• Core change marks the few waypoints where the change does its real work, with the reason. Your agent sets it when it explains the waypoint.

Must-read

The author of a change can mark the lines every reviewer should read as Must-read. A thin rule runs down the gutter beside those lines, and the first of them carries a small Must-read tag at its right end. The marks show on your own Flight Plan, on a teammate’s and on a published one.

On your own Flight Plan, select some code in the walkthrough and pick Highlight this change as Must-read for reviewers, the first button of the toolbar that opens. A mark that overlaps or touches another on the same file joins it. To take marks off, select any of their lines and pick Remove Must-read.

The marks are saved with the Flight Plan, so they go with it when you publish it as a Claude artifact. When the change gets new commits, a mark follows its lines as long as they’re still there together and unchanged, and is dropped otherwise. A Flight Plan a reviewer builds for themselves of your pull request has no marks.

The order of the files

Flight Plan sorts the files in the order of your review configuration: Building blocks first (the default), Entry points first or Most important first. You can pick another one for one review when you ask your agent to explain it. A Flight Plan its author arranged keeps the author’s order. Every changed file is covered whichever you choose.

Moving through it

• In the Review Navigator, Next waypoint (D) and Previous waypoint (A) step through the waypoints of a segment, across its files. Mark as reviewed (S) marks the waypoint you’re on.

• Filter (F) shows only the waypoints that match any of what you tick:

  • Must-read, the waypoints on lines the author marked, when the Flight Plan has any,
  • Core change, Bug, Risk, Nit or Question,
  • the kinds of code the review changes, each with what the change did to it, such as Component with Added. The topics of your spotlight come first,
  • Change type: Added, Modified or Removed, which narrows the others down to the waypoints of that change,
  • Reviewed, which brings back what you’ve marked reviewed.

  One filter covers the whole review, so a tick narrows the walkthrough of every segment. Changing a tick takes you to the first waypoint it keeps that you haven’t reviewed yet. While anything is ticked, a code block with none of the waypoints you asked for folds to its first line, and its chevron opens it again. The first time you open a review of someone else’s change, the filter starts with Must-read, Core change, Bug, Risk and the code blocks of your spotlight ticked. Your browser keeps the filter for each review, so it’s as you left it when you come back, cleared or not. The filter also stays in the page’s address, so you can share it.

On your own Flight Plan

On your own Flight Plan, Write description (C) on a waypoint opens its form: its title, its explanation, the Core change mark and additional context for your reviewers. A waypoint you haven’t described says so. You can also remove a waypoint, or a file from the walkthrough, and mark lines as Must-read.

Arrange files moves a file up or down. Once you arrange the files, the walkthrough keeps your order, for you and for your reviewers, whatever Code Walkthrough order they chose.