Advanced features
Give every agent its own review instructions, decide per pull request which agents review and which model tier each one uses, and register reusable Agent Skills the reviewer can call on.
1. Review Skills
A Review Skill is a Markdown file in your repository that tells one agent how to review. You write your conventions, the risks that matter to your team, and what to ignore — PURA supplies the rest. Every agent reads its own skill, so a security agent and a payments agent can review the same pull request with completely different eyes.
The skill is identified by the agent's machine-readable name — the folder holding the skill must match it exactly. For an agent named security-agent, PURA looks for SKILL.md in these locations, in order:
.agents/skills/<agent-name>/SKILL.md— the recommended location..claude/skills/<agent-name>/SKILL.md.github/skills/<agent-name>/SKILL.md
The first location that has the file wins. Skills are always read from the repository's default branch — never the pull request branch — so a pull request can never rewrite the instructions it is reviewed against.
If none of those files exist, PURA looks for an Agent Skill whose folder matches the agent's name, and finally falls back to its built-in instructions: code review agents review the changes, and PR quality review agents check that the pull request's title and description are present. A skill is entirely optional — every agent works out of the box.
A skill is a Markdown file, up to 64 KB. The YAML frontmatter is optional and carries the skill's name, description, and the optional .pura-routing field (see Routing). Everything after the frontmatter is the guidance the agent reviews with:
---
name: security-agent
description: Security-focused code review.
.pura-routing: |
Use this only for nodejs files. For large changes, use the high model.
---
Review for security issues: injection, secrets, and auth mistakes.
- Treat every request body as untrusted input.
- Flag direct string concatenation into SQL.
- Ignore formatting and naming.Skills are guidance, not commands. PURA treats repository content as untrusted: an instruction hidden in a skill — or anywhere else in your repo — asking the reviewer to approve a pull request or skip a check is never followed. It is reported as a 🔴 P1 finding instead.
2. Routing
The optional .pura-routing field in a skill's frontmatter is where you say, in plain English, when this agent should review and which model tier it should use. Write intent, not configuration — PURA works out the matching.
For each pull request, PURA evaluates the instructions once per agent against the pull request's changed files, description, commit messages, and diff size, using the agent's low model — a fast, inexpensive pass. The answer is one of four outcomes:
- none — this agent doesn't review this pull request.
- default — review with the agent's default model.
- high — review with the agent's high model, for changes that need deeper analysis.
- low — review with the agent's low model, for routine changes.
A few examples of what you can write:
- “Use this only for nodejs files” — matching pull requests review with the default model, others are skipped by this agent.
- “For large changes, use the high model” — matching pull requests get the deeper review.
- “Do not run if it's only doc changes” — docs-only pull requests are left to your other agents.
Routing is opt-in and free when you don't use it: with no .pura-routing, the agent reviews with its default model and no extra model call is made at all. If an evaluation cannot be completed — a provider hiccup, for example — the agent reviews with its default model and the run records a warning, so a pull request is never left unreviewed because routing was unavailable.
Routing selects agents and tiers — everyone still gets one review. Every agent that is active, has a working key, matches the pull request's scope, and wants the change reviews it, and all of their findings are consolidated into a single review on the pull request.
3. Agent Skills
An Agent Skill is a reusable, remote skill — a packaged set of instructions, conventions, or domain knowledge living in a GitHub repository — that you register on a review agent as a callable tool. Instead of repeating the same guidance in every skill body, the reviewer pulls it in only when it is relevant.
Available on Scale (10 skills) and Pro (25 skills). Agent skills are a plan feature — see pricing.
Add one to a review agent in the dashboard and point it at the skill's folder:
- Source —
github. - Organization & repository — where the skill lives, e.g.
acme/shared-skills. - Branch — which branch to read from, e.g.
main. - Path — the folder containing the skill's
SKILL.md, e.g.skills/finance-review.
Skills follow the Agent Skills specification. The SKILL.md declares a name and description, which become the tool the reviewer sees; the body is returned when the reviewer calls the tool. Only that one file is fetched — referenced scripts and assets are never loaded.
You can add several skills to one agent — each registers as its own tool, and the reviewer chooses when to use them. Two options are worth knowing:
- Sanitize — on by default: skill content is checked before it reaches the reviewer, and blocked if it contains sensitive information. Turn it off only for a source you fully trust.
- Invoke by default — off by default: turn it on to tell the reviewer to use that skill on every review, rather than at its own discretion.
If a skill's content cannot be read or is blocked by sanitization, that skill is skipped with a warning and the review carries on — your pull request is still reviewed. The same applies to models that don't support tools: the review runs with the diff alone, and skills simply stay out of the picture.

One skill, many agents. Skills live in your own repositories, so the same reviewed, version-controlled guidance can be shared across every agent and repository that needs it — edit it once, and the next review picks it up.