# Code reviewer on every PR Trigger a Nairi agent from CI on every pull request. It reads the diff, uses an open-source code-review skill, and posts inline review comments on GitHub. Nairi reviewing a pull request and posting inline comments on GitHub > 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 [#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 [#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](/help/integrations/llm-provider). * (Optional) A Slack channel for a TL;DR notification alongside the GitHub review. ## Step 1 — Connect GitHub [#step-1--connect-github] Install the Nairi GitHub App at [Settings → Integrations → GitHub](https://app.nairi.ai/settings/integrations) 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](/help/integrations/github) for the full walkthrough. ## Step 2 — Install the code-review skill [#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](/help/skills). The recommended skill is **[awesome-skills/code-review-skill](https://github.com/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: ```bash # 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](https://app.nairi.ai/settings/artifacts) → **New** → **Upload** and pick the `.zip`. See [Skills](/help/skills) for the package format and the [API reference](/api/skills/package-requirements) 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](https://github.com/anthropics/skills) ecosystem or your own private repo. The rest of this playbook applies unchanged. ## Step 3 — Create the agent [#step-3--create-the-agent] Open [Fleet → New agent](https://app.nairi.ai/agents/fleet) 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](/help/building-agents/how-to-deploy) for the full editor walkthrough. ## Step 4 — Base prompt [#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 [#step-5--rules-to-direct-the-agent] The skill gives you generic best practices. Rules localise them to your codebase. Open [Settings → Artifacts → Rules](https://app.nairi.ai/settings/artifacts) and attach a few to the agent. Suggested starting set: ### Style and conventions [#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 [#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 [#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 [#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](/help/building-agents/how-to-deploy#adding-rules) for the full editor reference. ## Step 6 — Trigger the agent from CI [#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`: ```yaml 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](https://app.nairi.ai/settings/access-tokens) in Nairi. See [Using the API](/help/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 [#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 [#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](/api/conversations/list-messages). * **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 [#related] * [Skills](/help/skills) * [Using the API](/help/using-the-api) * [API: Conversations — Start](/api/conversations/start) * [Connecting GitHub](/help/integrations/github) * [How to deploy an agent](/help/building-agents/how-to-deploy) *** *Can't find what you're looking for? Email [support@nairi.ai](mailto:support@nairi.ai).*