Origin Code Tours: Review Pull Requests in Order

A Code Tour is a guided reading of a pull request. Cursor reads the diff, groups related changes, and explains each group next to its code, in the order that makes sense to review rather than the order files happen to sort in. Every pull request on Origin has a tour on its Changes tab.

Each tour is written for its own pull request, so length follows the change. A small fix might get a few sentences, while a large change gets a longer walk through its parts. Most tours open with what the change does and why, written for someone who has not worked in that part of the codebase, and then go group by group.

The useful part is less the summary than the pointers along the way. Tours call out what deserves a closer look, such as behavior other code relies on, which is the thing a reviewer skimming a long diff is most likely to miss. If agents are writing a growing share of your pull requests, that is the part of reviewing agent code a tour actually helps with.

Origin is still in early beta, and Code Tours sit on top of its pull request flow.

Opening one takes two moves, and the keyboard shortcut is the one worth remembering since it toggles both ways.

1. 1At cursor.com/codebase, open a repository, select Pull Requests, and open a pull request.
2. 2On the Changes tab, select Tour in the Diff / Tour control, or press T.
3. 3Press T again to go back to the diff.

Most of what follows applies to pull requests in repositories created on Origin. GitHub pull requests in a mirrored GitHub repository get tours too, with fewer features. When you customize one there, everything except highlights is available, and Cursor writes tours ahead of time only for repositories created on Origin.

Navigation is built around sections, and your review progress carries over to the diff. That last detail is easy to overlook, but it means you can start in the tour and finish in the Diff view without losing track of what you have already read.

• Jump to a section: select the short lines at the top left of the tour to list its sections.
• Share a section: select the link icon next to a section heading to copy a link to it.
• Mark a section reviewed: check the box next to it to mark its files as viewed. The Diff view keeps the same progress.
• Expand a file: test files start collapsed, and deleted, generated and binary files may too.
• Read a definition: terms with a dotted underline show a short definition on hover or keyboard focus.

Screenshots and recordings from the pull request description, or from the cloud agent that authored it, may show up where they help. When an agent authored the pull request, the tour may also use the agent's notes on why it took its approach, what to watch for, and what it tested. That is probably the most useful input a tour can draw on, since it is the reasoning a reviewer would otherwise have to reconstruct from the diff.

To ask about part of a tour, select + next to a section heading to add it to the Ask Cursor box at the bottom of the page, or select a passage and choose Add to chat (Cmd I). Both appear when chat is available on the pull request page. A cloud agent working on the pull request can also edit the tour: rewrite a section, add a screenshot or recording, or write the whole thing again with different instructions.

Open the Generate custom tour menu next to the tour's title when the default does not fit. From there you can start with the highlights, choose which files the tour covers, set the depth, or add your own instructions.

History works through the version picker above the files. Pick a version, a commit or a range and the tour follows, or pick Changes since your last review to see only what moved since you last looked. For a second-round review that is, I'd say, the option to reach for first.

On pull requests with more than three files, a What next? card may appear after the last section, suggesting follow-ups such as Files you own or a Detailed version of this tour, plus Something else… to describe your own. It may also offer Add media to this tour, which asks a cloud agent to add screenshots, recordings, diagrams or tables.

The too-large case has an obvious answer that the docs state plainly: smaller pull requests each get their own tour, so splitting the work is the route back to having one. That lines up with the case for stacked diffs on Origin anyway.

Timing and billing are linked, so they are worth reading together. Cursor writes tours ahead of time only for repositories created on Origin and owned by a team, in the background when a pull request opens (drafts included) and when new commits are pushed. It is usually ready before the first reviewer looks.

Having Cursor write a tour when you open or request one needs a paid Cursor plan. On a free plan, or an individual plan still in its trial, you can read tours that already exist. If a tour fails partway, select Retry under Couldn't generate the tour, and if it keeps failing, check the plan first.

Code Tours follow the Privacy ModeCursor's setting that guarantees code data is not used for training by Cursor or its model providers, and that an admin can enforce org-wide; data-retention terms are a separate, contractual layer. Press Enter for the full definition. of the team or person who owns the repository, like the rest of Origin. To write a tour, Cursor sends the pull request's diff and description to a model. The tour is saved with the pull request, and anyone who can see the pull request can read it.