Skip to main content
The Code Reviewer agent reads your pull requests like a senior engineer. It returns structured findings, leaves inline comments on the exact lines, and reports a clear verdict back to your chat, so nothing is ever marked “done but unverified”.

​
How it works

Triggered automatically

When a specialist finishes a code change, the orchestrator hands it to the Code Reviewer before reporting back.

Reviews real PRs

The agent reviews the GitHub pull request, the same diff your teammates would see.

Structured findings

Each issue is categorized and tied to a file and line, with inline comments on the PR.

Verdict in chat

Approved or changes requested flows back to your chat, closing the loop.

​
Triggering a review

A review starts in one of two ways.
1

As part of a delegated task

When you ask the team to build or fix something, the orchestrator routes the resulting code change to the Code Reviewer as a validation step. You don’t have to ask for it, review is built into how work is delivered.
2

On demand

Point the team at an existing pull request and ask for a review. The Code Reviewer pulls the PR and evaluates it directly.
Review is the verification step that turns a code change into trusted work. The agent validates the change before the orchestrator tells you it’s complete.

​
Reviewing GitHub PRs

The Code Reviewer works against the pull request itself, title, description, and the full diff across changed files.
The agent loads every changed file in the PR and reviews additions, deletions, and context, not just the lines that changed in isolation.
Because the team has full context on your repository, findings reflect your actual conventions and surrounding code, not generic advice.
Correctness, edge cases, security, readability, and maintainability, the things a senior reviewer flags before approving.

​
Structured findings and inline comments

The review is not a wall of prose. Each finding is structured and placed where it matters.

Categorized findings

Every finding has a category and severity, so you can tell a blocking bug from a nice-to-have at a glance.

Inline comments

Comments land on the exact file and line in the PR, next to the code they’re about.
Inline comments keep the conversation anchored to the code. You can resolve them in GitHub like any other review thread.

​
The verdict flows back to chat

When the review finishes, its conclusion returns to the chat where the work began.
The change passed review. The orchestrator reports it back as verified, and the loop is closed, the work is genuinely done.
A change requested verdict means the work is not done yet. Orkestral surfaces this in chat so a flawed change never silently passes as complete.

​
Where this fits

Code review is the closing step of the team workflow: a specialist makes the change, the Code Reviewer validates it, and the verdict comes home to chat.

Meet the team

See every specialist and how the reporting hierarchy works.

Code changes

How the team turns a request into a reviewable pull request.