# Review Agents app

Review Agents is the portal's view of the reviews Solidafy Code Review posts on GitHub. Where GitHub shows you one pull request at a time, the app shows every reviewed pull request across your repositories, what the reviewers found, and the vulnerabilities and licenses of the dependencies those repositories declare. This page is for engineering leads and admins who want that wider picture.

The reviews themselves don't change: they still run on GitHub as described in the [Code Review overview](/docs/code-review/overview). The app reads what those reviews send to Solidafy, so there's nothing new to connect.

## What you need

- **Apps** switched on for your organization. Solidafy does this; if you don't see an **Apps** section at the top of the portal sidebar, ask your Solidafy contact.
- **Code Review** switched on for your organization. The app is only listed when your organization has both.
- An environment admin to start it. Anyone else can open it once an admin has started it and given them access (see [Who can open it](#who-can-open-it)).

Open it from **Apps** > **Review Agents**.

## Start

The first time an environment admin opens the app, it shows a Start screen with two steps.

**1. Connect GitHub.** What this step shows depends on where your organization is with Code Review:

- **No GitHub App yet.** Click **Install on GitHub** to install the Solidafy Code Review GitHub App and choose the repositories to review. It's the same install as the one in [Setup](/docs/code-review/setup), so everything there about choosing repositories and approval by a GitHub organization owner applies.
- **Being set up.** The GitHub App is installed and the reviews are being set up. The screen moves on by itself. If setup fails, it shows why, with a **Try again** button.
- **Reviews report to another environment.** The app reads your reviews in the environment they report to, which is the **Dashboard environment** on the Code Review settings page (see [Dashboard and dashboard environment](/docs/code-review/configuration#dashboard-and-dashboard-environment)). If that's a different environment from the one you opened the app in, click **Move them here**. The Code Review dashboard moves with them.
- **Already set up.** If your organization already uses Code Review in this environment, the step is ticked and you go straight on.

**2. Start.** Click **Start** to open the app on your reviews.

After Start, the app opens on the reviews already sent to this environment. If none have arrived yet, it says **Your reviews have not arrived yet** and, for an admin, shows how far setting up has got. You can leave the page: the numbers appear as soon as the first reviews land.

Someone who isn't an environment admin and opens the app before it's started is told to ask an environment admin to install it.

## Filters

Every view has the same filters at the top, and the address carries them, so you can share a filtered view as a link:

- **Repo**: one repository, or all of them. A repository with no owner team is marked **(no owner)**.
- **Owner team**: the team that owns the repository (see [Teams and repos](#teams-and-repos)), or **No owner yet** for repositories no team owns.
- **Period**: the last 7, 30 or 90 days. The default is 30. **Supply chain** has no period, because it shows what's open now.
- **Outcome**: on **Pull requests** only, **Changes requested**, **Stopped safely** or **Approved**.

**Clear filters** puts them back.

## Overview

The overview opens with a sentence or two summing up the period: how many pull requests were reviewed in how many repositories, how many got changes requested or stopped safely, how many blocking findings the verifier confirmed, and what it all cost. Pull requests opened by bots are left out of these numbers, and the overview says how many.

Below that are six key numbers, each with a bar for each of the last eight weeks and an arrow when it moved for the better or worse since the period before:

| Number | What it counts |
| --- | --- |
| **Pull requests reviewed** | Each review the reviewers finished, once per commit they reviewed. A review replaced by a newer one of the same pull request isn't counted twice. |
| **Changes requested** | The share of reviews with at least one blocking finding. |
| **Blocking findings confirmed** | Every blocking finding gets a second look from a separate verifier. This is the share it confirmed. |
| **Stopped safely** | The share of reviews that hit a time, step or spend limit, or couldn't read the change, and asked for a human instead of guessing. |
| **Review time (median)** | From a review starting to its comments being posted, for the middle review of the period. |
| **Spend** | What reviews cost from your credits in the period, verifier passes included. Reviews of bot pull requests cost too, so they count here. See [Billing](/docs/code-review/billing). |

Click a number to open the pull requests behind it. **How these are measured** shows the same explanations in the app.

**Findings** breaks down what was raised, **By severity** or **By agent**. By severity shows how many findings were raised at each severity and what share of the blocking ones the verifier confirmed. By agent shows, for each of the [six reviewers](/docs/code-review/overview#the-six-reviewers), how many findings it raised, how many were blocking, the share confirmed and how many were refuted.

**Worth a look** lists the five repositories with the most blocking findings in the period, with their owner team, reviews and open vulnerabilities, and says how many more had blocking findings. Click a repository to filter the whole app to it.

## Pull requests

**Pull requests** lists every reviewed pull request in the period, newest first, 25 to a page. Each row shows the outcome, the repository and pull request number, its owner team, how many blocking and advisory findings it got, the findings by severity, the size of the change and when the review finished.

Click a row to open it:

- **Findings**, grouped by file: each one's severity, title, explanation, reviewer and line, whether it's blocking or advisory, and whether the verifier confirmed or refuted it. A review with a very large number of findings shows the most severe ones and says so.
- **This review**: how long the review took, what it cost, the tokens it used, and what triggered it.
- What became of the findings after people replied: how many were resolved, how many stand, how many went to a human and how many were waived. See [Responding to findings](/docs/code-review/overview#responding-to-findings).
- **Open on GitHub** takes you to the pull request.

## Supply chain

**Supply chain** shows what's open now in the repositories you can see, in two tabs.

**Vulnerabilities** covers known security advisories that affect the dependencies your repositories declare. It shows how many are open at each severity (some may not have a severity from the scanner yet) and how many have been resolved since the first scan. **What to fix first** lists them two ways:

- **By advisory**: each advisory with its package, severity, how many repositories it affects and how long it's been open. Open one to see each affected repository, its owner team, the version in use, and when the advisory was first and last seen there.
- **By repo**: each repository with its open vulnerabilities at each severity and its open license findings.

**Licenses** sorts the licenses of your dependencies into **Strong copyleft** (GPL and AGPL, only shown when some is found), **Weak copyleft** (LGPL, MPL, EPL), **Non-standard** (custom terms to read), **Undeclared** (no license found) and **Not classified yet**. Pick a category to list each package, its license, the repository that uses it and the owner team. This is the same license check that runs on every review; see [Open-source licenses](/docs/code-review/overview#open-source-licenses).

## Settings

**Settings** is only shown to environment admins. It has five sections. Change what you need in any of them; a bar then shows how many settings you've changed, with **Discard** and **Review and apply**. **Review and apply** lists every change with its value now and after, and **Apply** saves them all at once. The next reviews use them straight away.

### Reviews, Budget, and Privacy and access

These are your organization's review settings: the same settings as on **Settings** > **Code Review**, so a change in either place shows in both. **Reviews** holds the reviewers and your guidance, **Budget** the spending and effort limits, and **Privacy and access** whether finding content is stored, plus [Who can open it](#who-can-open-it). Each setting is explained in [Configuration](/docs/code-review/configuration#organization-settings).

Ticket lookup, registry credentials, the dashboard environment, the per-repository overrides builder and **Generate repository guidance** are only on **Settings** > **Code Review**. See [Configuration](/docs/code-review/configuration) and [Private registries](/docs/code-review/private-registries).

### Teams and repos

Each repository with its owner team. A repository's owner team is the team that lists it among its repositories in Engineering Delivery's settings (the **People and Teams** link takes you there; see [Setting up Engineering Delivery](/docs/engineering-delivery/setup)). Owner teams only narrow what people see; everything is still read by repository. The section's name in the menu shows how many repositories have no owner yet.

### Connections

Whether the GitHub App is connected, being set up, or needs attention. Which repositories are reviewed is chosen on GitHub, in the app's installation (see [Setup](/docs/code-review/setup)).

### Who can open it

Environment admins can always open the app and see every repository. Anyone else needs an entry here:

1. Under **Find a person or a group**, search for and add a person or a group.
2. For each entry, choose what they see: **Every team**, or **Chosen teams** and tick the teams. Someone given chosen teams sees only the repositories those teams own, in every view.
3. Click **Review and apply**.

Until you add anyone, only environment admins can open the app. Someone without access who opens it is told they don't have access. The app reads everything with the viewer's own permissions, so any data policy that applies to them applies here too.

## Alerts

Everyone who can open the app gets in-portal alerts about the repositories they can see:

- When a repository has critical or high vulnerabilities open. You're alerted once per repository, until none is open.
- When noticeably more reviews stop safely than in the period before.

## Uninstall

At the bottom of **Settings**, the **Danger zone** has **Uninstall app**. It lists what it will remove, and you type **Review Agents** to confirm. Uninstalling removes what the app keeps of its own in this environment: its install, who can open it, and its alerts. It doesn't touch your reviews, the data they send or the Code Review dashboard, and it doesn't uninstall the GitHub App, so reviews carry on on GitHub. To stop reviews, see [Disconnecting](/docs/code-review/setup#disconnecting).

After an uninstall, the app opens on Start again. If an uninstall stops part way, the danger zone says where it stopped, and **Finish uninstalling** completes it.

## Asking from an AI assistant

The app also answers questions in AI assistants connected to Solidafy's hosted MCP server at `https://mcp.solidafy.com/mcp-public`. Once the app is started in an environment, anyone who can open it gets three tools there, answered with their own access, so they only see the repositories they'd see in the app:

| Tool | What it answers |
| --- | --- |
| `get_review_agents_overview` | How reviews went: the key numbers and the repositories with the most blocking findings. |
| `list_review_agents_pull_requests` | The newest reviewed pull requests, with each one's outcome and its blocking and advisory findings. |
| `get_review_agents_supply_chain` | Open vulnerabilities by severity, license findings by category, and the most severe open advisories. |

Each can be narrowed to a `repo` (`owner/name`) or an owner `team`, and the first two to a period with `days` (`7`, `30` or `90`). The answers stay at the repository level: they never include finding text or code. To connect an assistant, see [AI agents and MCP](/docs/cli/ai-agents).