Use case

Automated pull request review on every PR

Wire Nairi into your CI for an honest first-pass review on every PR. The agent runs your tests and linter, posts inline comments to GitHub, and summarizes back in Slack. Pick the harness per repo. Self-host the runtime if your code can't leave your infra.

What this looks like

Most teams want a baseline review on every PR. Tests passing, lint clean, obvious bugs flagged, security checklist run. The human reviewer comes in for the parts that need judgment, not for the parts a careful agent can catch first.

Nairi runs that first-pass review on every PR via a GitHub Action that calls the REST API. The agent clones the branch into its sandbox, runs your tests and linter, reads the diff against your custom rules and skills, posts inline comments to the PR, and summarizes back in Slack. Engineers can also ping the agent in Slack for an on-demand deep dive on a specific PR with a specific angle.

Honest framing: dedicated PR-review tools like CodeRabbit, Greptile, and Cursor Bugbot have deeper review-specific tooling. If PR review is the only thing you need an agent for, evaluate them. Where Nairi fits is when the same agent platform also handles on-call summaries, scheduled jobs, ad-hoc Slack questions, and shipping code from a Slack thread. One platform, one set of credentials, harness and model choice per agent, self-hostable.

What the agent does on a PR

The defaults teams reach for. Per-agent customization handles the rest.

Review every PR on open

A GitHub Action calls the Nairi REST API on PR open. The agent clones the branch, runs your tests and linter in its sandbox, reads the diff, and posts inline review comments to the PR with line-anchored suggestions.

Summarize the review back in Slack

Same review, posted as a one-paragraph summary in the Slack channel the team works in. Reviewers see the PR is ready to look at, with the agent's top concerns called out, before they open GitHub.

Customize the review style per repo

Reusable skills like "review for SQL injection risk" or "check that every new endpoint has a test". Custom rules per agent: "always flag missing telemetry", "always check that the migration is reversible". The agent follows your team's actual review checklist, not a generic one.

On-demand deep dive from Slack

Outside of the auto-review loop, ask the agent in Slack: "review PR #123 in foo/bar, focus on the migration logic". The same review machinery runs with the angle you asked for, and the result lands in the PR and the Slack thread.

Iterative back-and-forth

Engineer pushes more commits in response to the agent's review. Reply in the same Slack thread, "rerun the review on the latest commits, focus on the perf comment". The agent reads the new diff, re-runs tests, posts the updated review.

Pick the harness per repo

Different repos, different harnesses. Claude Code for one service, Codex for another, OpenCode for a third. The same review skills work across all of them. No global model lock-in.

Three scenarios teams use it for

The baseline review, the on-demand deep dive, and the review-fix-review loop.

01

Baseline review on every PR, before a human looks

Add a workflow file that fires on every PR open. It calls the Nairi REST API with the repo, the diff, and your review skills. The agent runs your tests and linter, reads the diff against your custom rules, posts review comments to the PR, and sends a one-paragraph summary to Slack. The human reviewer opens the PR with context already on the diff: tests pass, lint is clean, two specific concerns flagged. The review starts as a focused conversation instead of a cold read.

02

Deep dive on a tricky PR, on demand

A PR touches the auth refactor. Engineer pings the agent in Slack: "review PR #427 in auth-service, focus on session invalidation on logout and check every place we read the session cookie". The agent re-runs the review with that lens, posts the focused comments, summarizes back. Saves the senior engineer an hour of grepping before they start reviewing.

03

Review-fix-review loop

First-pass review posts five comments. Engineer addresses three, pushes new commits. From the same Slack thread: "rerun, focus on whether the perf comment is resolved". The agent reads the new commits, checks the perf path, posts an updated review. The loop closes faster than ping-ponging a human reviewer over multiple days.

How it works

One agent, encoded review style, triggered by your CI. No new platform for the team to learn.

  1. 1

    Connect the agent to your repos

    Install the Nairi GitHub app on the repos you want it to review. Read-only is fine for review-only workflows; write access enables the agent to also open follow-up PRs or push fix commits if you want.

  2. 2

    Encode your review style as skills and rules

    Per agent: skills like "Security review checklist", "Database migration review", "API contract review". Custom rules in plain English: "always flag a new public endpoint without rate-limiting", "always check that a new env var is documented in the README". Reusable across PRs and across repos.

  3. 3

    Wire the agent into your CI

    Add a GitHub Action that calls the Nairi REST API on PR open (and re-open, and synchronize). Pass the agent ID, the diff, and any per-PR overrides. The agent reads its config from the platform; you just call it.

  4. 4

    Review runs in the sandbox, posts to GitHub and Slack

    Each invocation spins up an isolated container with your toolchain. The agent clones the branch, runs your tests and linter, runs the review against the diff and your skills, posts review comments to the PR, and summarizes to Slack. Self-host the runtime via the open-source nairid daemon if your code can't leave your infrastructure.

Add a first-pass reviewer to every PR

Encode your review style as skills, wire the API into your CI, start in shadow mode. The same agent handles on-call summaries, Slack questions, and scheduled jobs. One platform, one set of credentials.

Questions about PR review use

What dev teams ask before they wire it into CI.

Inline review comments, line-anchored to the part of the diff each comment is about, plus a summary comment at the top of the PR. Same shape as a careful human reviewer. The summary covers: tests passing or failing, lint output, the top two or three concerns the agent has with the diff, and any context the agent thinks the human reviewer should know before they read the code. The Slack post is a tighter one-paragraph version of the same.
Honest answer: those are dedicated PR-review specialists and the depth of their review-specific tooling is real. If PR review is the only thing you need an AI agent for, evaluate them seriously. Where Nairi fits differently: it's a general team agent that also does PR review. The same agent that reviews PRs can answer questions in Slack about production, draft on-call summaries, write a migration script, run a scheduled job. One agent platform, one set of credentials, one vault, one billing relationship. Plus harness optionality (Claude Code, Codex, OpenCode, Cursor), self-host of the runtime, and per-agent customization via skills and rules.
Add a GitHub Action that fires on pull_request open and synchronize. The Action calls the Nairi REST API with your agent ID, the PR diff, and the repo. The agent runs the review and posts results to the PR. We have an example workflow in the docs; most teams adapt it in 10-15 minutes. There's no built-in @-mention from inside a GitHub PR comment; triggers come from Slack, Discord, or the REST API.
Yes. Each invocation spins up an isolated container with shell access and your toolchain pre-installed (Node, Python, Go, Rust, common package managers; you can add anything else). The agent clones the branch, installs deps, runs your test command, runs your linter, and incorporates the results into the review. If a test fails, the inline comment points at the diff lines that likely caused the failure plus the test output.
Two layers. Skills are reusable procedures the agent can invoke, like "Security review checklist" or "Database migration review" or "Frontend accessibility review". Custom rules are persistent instructions at the agent level, like "always flag a new env var that isn't documented" or "always check that a new public endpoint has rate-limiting". You write them in plain English and version them like any other config. Per-repo or per-agent, your choice.
Per agent: Claude (Sonnet 4.6, Opus 4.7) via Claude Code, GPT-5 via Codex, open-weights via OpenCode, or the Cursor harness. Bring your provider key. Pick the model per agent: one repo on Claude where it's strong on TypeScript, another on Codex for the migration agent, a third on OpenCode if you have an air-gapped requirement.
Depends on whether you self-host. On the managed offering, the agent's sandbox runs in Nairi's cloud and clones your branch into the container. On the self-hosted path, the open-source nairid daemon runs the full agent loop, including the sandbox, on your hardware. Slack/Discord messages route through the Nairi backend for delivery, but the code, the diff, and the test execution stay inside the daemon you control. Useful for regulated workloads or for teams whose code can't leave the corporate network.
Two ways. Short term: tell the agent in the PR comment thread, "this is intentional, the linter rule is suppressed for compat reasons". The agent reads the thread and adapts. Long term: add a custom rule like "don't flag missing types in the legacy/ directory" at the agent level, so the false positive doesn't recur. Reviews tighten over weeks as the rule set learns the codebase.
Pick one repo and one skill ("Security review checklist" is a common starting point because the agent rarely overrides a human's judgment, it just adds a checklist pass). Add the Action, run it on a few PRs in shadow mode (post to Slack only, not to the PR). Tune the rules for a week. Then promote to PR-comment mode. By the time you roll it out across more repos, you have a calibrated config and the team has trust in the output.