Code reviewer on every PR

The recording shows the agent posting as eksec.ai — that's the product's previous name. The product was rebranded to Nairi in March 2026.

Outcome

An agent that wakes up on every pull_request event, clones the repo, reviews the diff using an opinionated code-review skill, and posts inline comments on the PR. No human has to mention it; CI does.

Prerequisites

• GitHub access to the repos you want reviewed, via the Nairi GitHub App.
• An LLM provider connected. Claude Sonnet via the Anthropic integration is the recommended pick for this playbook. See Connecting your LLM provider.
• (Optional) A Slack channel for a TL;DR notification alongside the GitHub review.

Step 1 — Connect GitHub

Install the Nairi GitHub App at Settings → Integrations → GitHub and grant access only to the repos that should be reviewed. The same App that lets the agent clone the repo will also let it post PR reviews via gh.

See Connecting GitHub for the full walkthrough.

Step 2 — Install the code-review skill

You don't have to write the review methodology yourself. Use an open-source one and bring it into Nairi as a custom skill.

The recommended skill is awesome-skills/code-review-skill — MIT-licensed, ~14k lines of curated review guidance covering 17+ languages and frameworks (TypeScript, React, Vue, Rust, Go, Python, Java, etc.). The skill description tells the agent when to invoke it, and the body covers what to look for, how to phrase findings, and severity labels ([blocking], [nit], [praise]).

To install it on your org:

# Clone the skill
git clone https://github.com/awesome-skills/code-review-skill /tmp/code-review-skill

# Package it as a .zip (Nairi accepts .zip or .skill, up to 32 MB)
cd /tmp/code-review-skill && zip -r ../code-review-skill.zip . -x ".git/*"

Then open Settings → Artifacts → Skills → New → Upload and pick the .zip. See Skills for the package format and the API reference for the full constraints (max 32 MB, allowed subdirs are scripts/, references/, assets/).

If you want a different style — terser, more workflow-driven, or focused on a single language — point to a different SKILL.md package from the anthropics/skills ecosystem or your own private repo. The rest of this playbook applies unchanged.

Step 3 — Create the agent

Open Fleet → New agent and fill in:

• Name — reviewer or pr-reviewer. The CI workflow in Step 6 will reference this name.
• LLM integration — Anthropic (Claude Sonnet). Reasoning over a diff benefits from Sonnet.
• Repository — leave blank. CI passes the repo per task.
• Skills — attach the code-review-excellence skill from Step 2.
• MCPs — none needed for the GitHub side; the agent posts reviews with gh via the GitHub App. Add Linear or Jira if you want it to cross-reference tickets.
• Channel — optional. Bind to a #code-review Slack channel if you want a TL;DR posted there.

See How to deploy an agent for the full editor walkthrough.

Step 4 — Base prompt

Keep it short. The skill carries the methodology; the prompt sets identity and the publishing flow.

You are a senior engineer reviewing pull requests for our team.

For each PR you are asked to review:
1. Use the code-review-excellence skill for methodology.
2. Produce a 2-line TL;DR of what the PR does.
3. Surface the most important issues, in priority order, as
   inline review comments on the specific file and line via
   `gh pr review --request-changes` (or --approve for clean PRs).
4. Each finding must include a concrete suggested change, not
   just "consider X".

Be terse. Skip nits unless they're load-bearing. Skip draft PRs.
Never merge.

Step 5 — Rules to direct the agent

The skill gives you generic best practices. Rules localise them to your codebase. Open Settings → Artifacts → Rules and attach a few to the agent. Suggested starting set:

Style and conventions

The most useful rule for trust. Once the agent stops flagging things that match your style, the team starts taking its findings seriously.

# Style and conventions

- TypeScript: no `any`. Prefer `unknown` + narrowing. PR comments
  that flag `any` are blocking.
- Imports: absolute paths from `@/`. Relative imports beyond
  `../../` are blocking.
- Errors: throw typed `AppError` subclasses, never plain `Error`.
- Tests: every new function in `src/lib/**` needs at least one
  unit test. Flag PRs that don't include one.
- Comments: only when the *why* is non-obvious. Don't ask the
  author to add comments to self-explanatory code.

Security checklist

Auth, input validation, secrets. Tightens the security signal without falling back on vague advice.

# Security review checklist

When reviewing changes that touch any of these areas, do not
approve without explicit verification:

- Authentication: any new route handler must check the session.
  Flag missing checks as [blocking].
- Authorization: any data access must scope by user_id / org_id.
  Cross-org leaks are [blocking].
- Input validation: external input (request bodies, query params,
  headers, webhook payloads) must be validated with Zod or the
  equivalent before use.
- Secrets: never log tokens, passwords, or API keys. If a token
  appears in a log statement, flag as [blocking] and suggest
  redaction.
- SQL: all queries must be parameterised. String-concatenated SQL
  is [blocking].

Sensitive areas

Tells the agent where to slow down.

# Sensitive areas

Apply extra scrutiny to changes in:

- `migrations/` — destructive ops (DROP, ALTER not-null) require
  a rollback plan in the PR description.
- `src/billing/` — pricing and invoice math. Every change needs
  a test asserting the expected dollar amount.
- `src/auth/` — token handling, session management, OAuth flows.
  Any change is [blocking] unless paired with a security review.
- `infra/` — Terraform / Pulumi. Ask the author to attach a
  `plan` output to the PR.

Tone

Sets the bluntness dial.

# Tone

- Treat the author like a peer, not a junior.
- One-line findings are fine; don't pad with context the author
  already has.
- Don't apologise. "This is a security issue" beats
  "I'm not sure but this might be a security issue".
- End approvals with a one-line summary of what you liked. Skip
  approvals on PRs you didn't actually love.

You don't need all four on day one. Start with style and security, then add the others as you notice misses.

See Adding rules for the full editor reference.

Step 6 — Trigger the agent from CI

Add a GitHub Action to the repos you want reviewed. The Action POSTs to the Nairi public API and the agent picks up the job; the review appears on the PR a couple of minutes later.

Create .github/workflows/nairi-review.yml:

name: Nairi code review

on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]

jobs:
  review:
    # Skip drafts; let synchronize re-review on push (debounce in the
    # agent rules if you want).
    if: github.event.pull_request.draft == false
    runs-on: ubuntu-latest
    steps:
      - name: Trigger Nairi review
        env:
          NAIRI_API_KEY: ${{ secrets.NAIRI_API_KEY }}
          NAIRI_AGENT_ID: ${{ vars.NAIRI_AGENT_ID }}
          PR_URL: ${{ github.event.pull_request.html_url }}
        run: |
          curl -fsSL --retry 3 \
            -X POST https://api.nairi.ai/api/public/v1/conversations/start \
            -H "Authorization: Bearer $NAIRI_API_KEY" \
            -H "Content-Type: application/json" \
            -d "$(jq -n \
              --arg aid "$NAIRI_AGENT_ID" \
              --arg url "$PR_URL" \
              '{
                agent_id: $aid,
                prompt: "Review the pull request at \($url). Use the code-review-excellence skill. Post findings as inline review comments on GitHub via gh pr review."
              }')"

Two repo settings to wire up before the first run:

• NAIRI_API_KEY as a repo or org secret. Create it at Settings → Access Tokens in Nairi. See Using the API for key handling.
• NAIRI_AGENT_ID as a repo or org variable. Use the agent's slug (the name from Step 3, e.g. reviewer) or its cci_… ULID.

The Action exits as soon as the API request returns (the review itself runs asynchronously on Nairi). The agent picks up the job, clones the repo at the PR's head SHA, runs the review skill, and posts results back via the GitHub App's token. Total wall time is usually 1–3 minutes per PR.

Step 7 — First run

Open a PR. Within a minute or two, you should see:

1. The GitHub Action run pass.
2. A pending review appear on the PR from the Nairi bot, with inline comments on the relevant lines.
3. (Optional) A TL;DR posted to the configured Slack channel.

If the first review is noisy, the lever is usually the rules. Look at what the agent flagged that you don't care about, encode that as a [nit]-only rule, and try again.

Customisation

• Pre-merge gate vs. advisory. The default is advisory — the action posts a review but doesn't block merge. To make a [blocking] finding actually block, add a follow-up Action step that polls the conversation messages and fails the job if the agent labelled anything [blocking]. See API: Conversations.
• Slack TL;DR. Add an MCP for Slack (or a skill that posts via webhook) and a rule: "After posting the review on GitHub, post a 2-line TL;DR to #code-review linking back to the PR."
• Skip rules. Auto-skip PRs labelled chore, docs-only, or that touch only .md files. Add a if: clause to the GitHub Action job.
• Auto-approve tiny diffs. For renames or PRs under N lines, instruct the agent (via a rule) to leave a one-line approving review instead of an empty one.
• On-demand from Slack. In addition to CI, let your team trigger an ad-hoc review by mentioning the Nairi bot in a channel bound to the reviewer agent: @Nairi review https://github.com/.... Same agent, no extra setup — the channel mention starts a conversation the same way the API does.

Related

• Skills
• Using the API
• API: Conversations — Start
• Connecting GitHub
• How to deploy an agent

Can't find what you're looking for? Email support@nairi.ai.