> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stoutdata.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# PR Reviewers

> An AI reviewer that authors and runs hardware tests against every pull request, then reports back as a GitHub check.

<Note>
  **Beta.** PR Reviewers is in limited availability while we validate it on real
  fleets. It may not be enabled on your deployment or organization yet — reach out
  if you'd like to pilot it.
</Note>

A **PR Reviewer** watches a GitHub repository and, on every pull request, uses an AI model to **author hardware tests for the change**, flash the relevant firmware onto a real box, run those tests, and post the result back to GitHub as a check. It closes the loop between "someone opened a PR" and "we know whether it works on hardware" — without a human hand-writing a test for each change.

This is different from a fixed, hand-maintained test suite (that's [Factory](/source/factory/overview)). A PR Reviewer reasons about the diff and generates the tests it thinks the change needs.

## Prerequisites

* The **GitHub integration** connected for your org, with access to the repo. See [GitHub](/source/integrations/github).
* At least one **box** online with the instruments the tests will need.

## Creating a reviewer

From **PR Reviewers → New**, configure:

* **Repository** — `owner/repo`. Add **path prefixes** to scope the reviewer to part of a monorepo, so a PR only triggers it when it touches those paths (one reviewer per product).
* **Model** — the Claude model that authors and drives the review (Claude Opus 4.7, Sonnet 4.6, or Haiku 4.5; Haiku 4.5 is the default).
* **Firmware source** — either a **prebuilt** binary at a path in the repo, or a **CI artifact** pulled from a named GitHub Actions build workflow (by artifact name or regex pattern). Optional flash load address and erase.
* **Boxes** — run on any online box, or restrict to an **allowed list**. You can also require specific **net types** so a run only lands on a box that actually has the hardware. An optional box-selection mode ranks candidate boxes automatically.
* **Tests** — where generated tests are written and run (single file or directory module), extra files to include, and a per-run timeout.

## Guardrails and automation

Each reviewer has controls for how far the AI is allowed to go on its own:

* **Human approval** (default **on**) — pause each run for a designated person to approve before anything flashes or runs on hardware.
* **Commit generated tests** — commit the tests the reviewer wrote back to the PR branch.
* **Agentic self-heal / code & firmware remediation** — let the reviewer iterate (up to a configurable number of rounds) to fix a failing test or propose a fix, rather than just reporting red.
* **Pass triage** — have the model sanity-check passing runs.
* **Rate limit** — cap runs per hour (1–1000) so a storm of PR updates can't monopolize the fleet.
* **Slack** — post run notifications to a channel.

## Runs and approvals

Every matching pull request creates a **run**. Runs that are waiting on human approval collect in an **awaiting-approval** queue — the count shows as a badge on the PR Reviewers sidebar item. Open a run to see the model's reasoning, the generated tests, the flash and test logs, and the final verdict. The same verdict appears as a **Stout** check on the PR in GitHub.

## Related

<CardGroup cols={2}>
  <Card title="GitHub integration" href="/source/integrations/github">
    Connect the GitHub App so Stout can read PRs and post checks.
  </Card>

  <Card title="Webhooks" href="/source/integrations/webhooks">
    How GitHub pull-request events reach Stout to trigger a review.
  </Card>
</CardGroup>