Reviewing a pull request

Open a pull request from the list and you land on its review page: the title and number at the top, a status pill (Open / Merged / Closed), and a Pull Requests link back to the list.

How do I turn it into work, or discuss it?

A strip right under the title:

• If it is not linked to a card yet, you will see Create Card and Discuss in chat (each shown only if you hold the matching permission; if you hold neither, the strip does not appear at all).
  • Create Card opens Create card from pull request, pre-filled with a title ([PR #<number>] <title>). The dialog also has an Additional instructions (optional) field. This starts empty; the pull request itself and its latest analysis are attached to the new card automatically, so you only need to type extra constraints or acceptance criteria if you have any. Click Create card (or Cancel). The new card is linked to this pull request automatically.
  • Discuss in chat opens a Chat conversation seeded with this pull request's context. If it cannot open, you will see "Could not open the pull request conversation."
• Once a card is linked, the strip instead shows Linked issue: with the card's title as a link, plus Discuss in chat and, if you have permission, an Unlink button to remove the link.

If the pull request has a description, it is shown next in its own Description card, rendered from the original text.

The Files / Analysis / History switcher

A View dropdown (in the Summary panel) switches the main pane between three views. It opens on Analysis.

Files

The diff viewer:

• A filter box ("Filter files by name or path…") narrows the file tree as you type, showing a count like "3 of 12 files."
• Expand all diffs / Collapse all diffs toggles every file's diff open or closed at once.
• A folder tree, built from the changed files' paths, with expandable and collapsible folders (chevron and count).
• Each file is its own card: file name, change type (added / removed / renamed / modified / changed), and a green "+N" / red "−N" line-count summary. Click a file's header to expand or collapse just that file.
• Inside an expanded file: added lines in green, removed lines in red, hunk headers (@@) in a muted band, unchanged context in the default color. Binary or undiffable files show "No textual diff available (binary or large file)."
• No filter matches: "No files match your search." No changed files at all: "No file changes found."

Files are fetched from the provider only the first time you open this view, then cached for the rest of your visit.

Analysis

ACE's AI code-review report:

• No analysis yet: "Run a code analysis before approving or merging." with a Run analysis button (if you have pr:review), and a note pointing to Rules for automatic-analysis settings.
• In progress: "Analysis in progress… approval actions unlock when it completes." with a spinner. It updates on its own as soon as it finishes (the page polls quietly in the background, capped after 100 checks, so it will not poll forever if something never completes).
• Failed: "The previous analysis failed," with the captured error message, and a Run analysis button to retry.
• Complete: a green "Analysis complete" line, a Re-run button, and the full write-up below.

Approve and Merge are both blocked until an analysis has completed at least once.

History

The audit log: every recorded decision (approved, rejected, merged), each with who did it, how long ago, and any reason or comment attached. When there is nothing yet: "No actions recorded yet."

The Summary panel

On the right, a sticky Summary card:

• Source control: repository name, provider and connection-type badges, and an Open on GitHub / Open on GitLab link to the provider's own page.
• Status: the state pill, review state (Approved / Changes requested / Commented / Pending / No review), whether it is mergeable, and a "has conflicts" flag if relevant.
• Branches: source → target.
• Changes: four stat tiles: Commits, Files, Additions, Deletions.
• Author.
• Timeline: created and last updated.
• Reviewers: if any are set, each with its own review-state badge.

The View dropdown and the decision buttons sit in the card's footer, visible as you scroll the main pane.

Decisions: Approve, Reject, Merge

Whether you see these buttons depends on your role; each also has its own enablement rule:

• Approve (pr:review): enabled only while the pull request is open and its analysis has completed. It confirms with a dialog: Approve <title> (#<number>) in the platform and on GitHub/GitLab.
• Reject (pr:review): enabled while the pull request is open, and does not require analysis to have finished. The dialog asks for a reason (required, minimum 3 characters): Rejecting <title> (#<number>) records the decision in the platform. When 'Post rejection as comment' is checked, the reason is also posted as a comment on GitHub/GitLab. A Post rejection as comment on GitHub/GitLab checkbox is checked by default; uncheck it to record the rejection only inside ACE.
• Merge (pr:merge): only appears with merge authority, and is only clickable once all of these hold: the analysis has completed, there are no conflicts, the provider reports it mergeable, the pull request is still open, and the repository allows at least one merge strategy. It confirms with Are you sure you want to merge <title> (#<number>)? This will perform the merge on GitHub/GitLab and update the platform decision., then lets you pick a Merge strategy (for example merge, squash, or rebase, whichever your repository allows) and confirm.
• Merge conflicts: while the pull request is open and conflicted, Merge is replaced by Solve conflicts, which opens the pull request directly on GitHub or GitLab in a new tab (conflicts have to be resolved on the provider itself). A conflicted pull request that is already closed or merged shows neither button.

Any decision's error, if one occurs, appears as plain text below the buttons.