Skip to main content
Capy reviews pull requests with a dedicated review agent. It reads the diff in a real checkout of your repository at the PR’s exact head, and posts findings as inline GitHub comments. Every finding is also recorded in Capy and relayed to responsible agent threads.

​
Findings

Each finding names a failure scenario and carries a category, a severity, a confidence, and a file and line. Confirmed means the diff plus traced context proves the defect, investigate means a concrete risk with a verification target. A review can also leave notes: anchored observations that name no failure, like a “this looks wrong but is correct, because X” verdict.

​
Starting a review

  1. Automatically per repository. Set each repository’s mode in Settings → Review: Off, Once (first review when a PR opens), or Every push. Enabling reviews for a repository takes its review billing for your org.
  2. Manually from the dashboard. Open a pull request in Capy and start a review from its page.
  3. From a PR comment. Comment @capy review on the pull request. Trailing text becomes the round’s extra instructions: @capy review focus on the migration.
  4. From the API. POST /api/v1/reviews starts a round for a repo and PR number, see the API reference.
A push while a review is running starts a fresh round against the new head. When a review runs on a PR a Capy thread opened, the thread receives the verdict and triages the findings itself.

​
What posts to GitHub

Findings at or above the repository’s posting threshold post as inline review comments. The default threshold is medium; repository settings can change it, toggle whether investigate findings post, and opt notes in. Re-reviews don’t flag the same issue twice. When a finding is marked resolved or irrelevant, Capy resolves the corresponding GitHub thread.

​
Triage

Each finding has a triage status. When a Capy thread owns the pull request, it triages after each review: it marks false positives irrelevant, confirms fixed issues as resolved, and fixes high-severity issues before reporting the PR ready. You can override any triage decision from the dashboard.

​
Re-reviews

Re-reviews are incremental: only code changed since the last reviewed head is in scope, with the whole PR as context. Open findings carry forward, and the agent marks the ones it verifies are gone as resolved. Findings you marked irrelevant are never re-flagged; a resolved finding whose fix didn’t hold comes back as a fresh finding.

​
Steering reviews

The review agent reads your repository’s AGENTS.md files and enforces the conventions written there as findings, on the same footing as logic bugs. Write the rules you want enforced, or the patterns you never want flagged:
Changes take effect on the next review. The deprecated .capy/REVIEW.md per-agent file is no longer read.