Review pull requests

A PR Story turns a large diff into a small number of reviewable chapters. Each chapter explains one meaningful outcome and shows only the code associated with it.

Read the overview first

The top of the story explains the reason for the pull request and its important result. If the available evidence does not explain the intent, Fullbeam says so instead of inventing one.

The review-focus list contains only the main non-obvious areas that need judgment.

Work through the chapters

On desktop, each open chapter is split into two panes:

• Left: the explanation, risk, important claims, discussion, and file links.
• Right: the code changes associated with that chapter.

On smaller screens the same content is stacked. Select any file or citation to jump to its code.

Chapters represent outcomes, not files. One chapter may contain several files when they work together to implement one behavior.

Understand risk tags

• Inspect means the cited change deserves careful review.
• Skim means the chapter appears lower risk based on cited evidence.

Risk tags help prioritize attention. They are not approval decisions.

Mark progress and hand off to GitHub

Mark a chapter as reviewed after checking its explanation and code. Use the GitHub handoff when you are ready to approve, request changes, or submit a GitHub review.

If the PR changes later, Fullbeam compares the new revision with your checkpoint. Unchanged chapters keep their continuity; changed or newly risky chapters need another look.

When agent context is missing

Missing agent telemetry does not block a story. Fullbeam can still organize the PR from GitHub metadata and the diff. The How it was built section only shows runtime evidence that is actually available.