Add opt-in grouped pull request reviews with a configured agent

[itsfaqih]

Problem

Large pull requests can touch files across several concerns. Reviewers have to work out which files belong together, understand each part of the change, and keep track of where they left off.

pulls.review groups related files and summarizes each group. A similar workflow in T3 Code’s Pull Requests view could keep those review notes close to the PR and its diffs.

Proposed behavior

• Add a "Review with agent" action to the PR view. Run it only when the user starts it.
• Use an enabled coding-agent instance configured in the current T3 environment. Reuse the selected provider from the linked thread when there is one. Otherwise, let the user choose a configured provider before starting a review thread.
• Fetch the PR diff through T3 Code’s source-control connection and ask the agent to group related files and summarize each group.
• Show each group with links to its files and diff hunks. Let the reviewer inspect groups and save review progress.
• Tie each result to the PR revision it analyzed. Refresh the analysis when new commits arrive.
• Keep generated summaries advisory. Posting comments or submitting a review should require a separate user action.

Related discussions

• #15276: Support CodeRabbit Autofix and Autopilot actions in the PR panel
• #6695: /review slash command for automated code review

This proposal focuses on organizing a person’s review of a PR in T3 Code.

[acidoxee]

Copying my comment from the other discussion since this one may be better suited:

I'd use this a lot if it could be embedded in T3 Code itself, since using outside tools always breaks the flow. Other tools doing something similar: codiff (LLM walkthroughs), godiff (groups files by intent using a locally installed agent), and Linear's PR review guides, which inspired pulls.review.

A few suggestions:

1. Don't limit it to PRs. Most diffs I review in T3 Code are turn or branch diffs an agent just wrote. The grouped view would be just as useful in the Diff panel
2. Every changed file should land in a group. Anything the model leaves out should go into a visible "Other" bucket, so trusting the groups never means missing a file
3. Suggest a reading order: core change first, then where those changes are being put to work, tests, config/infra, and generated files collapsed. The tools I mentioned do this well
4. Reuse the existing Viewed state for per-group progress (e.g. "3/5 viewed")

[Kameleon21]

+1. The review guides beta (#18124) covers much of this already: stops in reading order, each changed file assigned to a stop, and a configurable guide model. I'd like one more option on top of it: group by commit.

When a PR is made of meaningful commits, the guide could follow them instead of choosing its own grouping:

1. One stop per commit, with an AI-written title, for example "First: update X so it does Y". Under the title, show the files and folders that commit touched.
2. A short smart summary for each file or hunk in place of the raw list of changes, so you can skim a step before opening its diff.
3. A cheap model by default. These summaries are small jobs, so the smallest or cheapest model the user has configured is enough.
4. Show it in the PR sidebar next to the chat, so you can step through the commits while talking to the agent.

This builds on the per-commit Diff view proposed in #6924. That gives the raw commit diffs, and this adds a readable story on top of them.