Cursor 3.8 Code Review with Subagents and Skills

By Rogier Muller06.22.26
Cursor 3.8 Code Review with Subagents and Skills

Cursor 3.8 makes review automation more useful for engineering teams because Automations can now be created from a local agent session with /automate, triggered from GitHub and Slack, and allowed to use computer actions where appropriate. A Cursor code review workflow is a repeatable path from change to review receipt: rules, skills, agent instructions, and evidence that a teammate can inspect.

Turn /automate into a review habit

Cursor now lets you use /automate to create an automation from the local agent session. The useful move is simple: describe the review job in the place where the code context already exists.

For example, ask Cursor to create an automation that watches GitHub pull requests with the api label, checks the diff against your repo rules, and posts a short review receipt back to the PR. The agent has a bounded job: inspect, suggest, cite files, and stop.

Don't ask for a vague “review everything” automation. Good automations have a trigger, a scope, a rule set, and an output. If one of those is missing, the agent will fill in the blanks in ways your team may not like.

Put review boundaries in AGENTS.md and Cursor rules

Use AGENTS.md for durable repo behavior and Cursor rules for the IDE-level instructions your agents should follow. The pattern is especially helpful when you use cursor subagents or named agent roles like “security reviewer,” “migration reviewer,” or “frontend accessibility reviewer.”

A practical boundary in AGENTS.md might say: “API changes must include an OpenAPI diff, a migration note, and a rollback plan.” A matching .cursor/rules/review.mdc file can tell the agent how to check that boundary during review.

Don't put every preference in one root file. Review guidance works better when it is close to the code it governs: service-level rules near services, frontend rules near frontend packages, and database rules near migrations. Nested boundaries reduce noise and make Cursor custom agents easier to trust.

Use skills for review moves you repeat

Cursor skills are reusable instructions and supporting material that an agent can pull in when a task needs that capability. For review work, a cursor skill should describe one repeatable move: review a migration, check a React accessibility change, compare API behavior, or prepare a refactoring plan.

A useful skill description is specific enough to activate at the right time. “Review PostgreSQL migrations for locking, backfill safety, rollback behavior, and application compatibility” is better than “Review database stuff.”

Don't treat skills as long prompts. A skill is not a dumping ground for taste. Keep it focused, include examples, and make the expected review receipt obvious. For more team patterns, see Cursor subagents and skills.

Keep GitHub, Slack, and MCP narrow

Cursor 3.8 adds new Automation triggers for GitHub and Slack, which is a strong fit for review workflows. Use GitHub for code events, Slack for human escalation, and MCP when the review needs external context such as tickets, design docs, production runbooks, or internal service catalogs.

MCP is the integration layer that lets an agent connect to external tools and data sources through a standard protocol. In a review workflow, that might mean fetching the Jira ticket behind a PR, checking a design document, or reading a service ownership record before making a recommendation.

Don't give review automation broad access before the team has a receipt habit. Start read-only where possible. Then add write actions, Slack posting, or computer use only when the output is already boring, predictable, and easy to audit.

Paste this review receipt into your repo

Use this as the artifact your Cursor Automation must leave behind. It works as a PR comment, a review-receipt.md file, or the required final response for a review-focused cursor custom subagent.

# Cursor review receipt

PR: <link>
Reviewer agent: <name or automation>
Triggered by: GitHub PR | Slack request | manual `/automate`
Scope reviewed: <files, packages, or services>
Rules used:
- AGENTS.md: <paths consulted>
- Cursor rules: <.cursor/rules/*.mdc consulted>
- Skills: <skills used>
- MCP context: <GitHub/Jira/docs/etc., or "none">

## Summary
- <1-3 sentences on what changed>

## Blocking findings
- [ ] <file:line> <issue> — <why it blocks merge>

## Non-blocking findings
- [ ] <file:line> <suggestion> — <tradeoff or follow-up>

## Refactoring notes
- <safe refactor suggested, or "none">

## Tests and evidence
- Commands inspected or run: `<commands>`
- Existing tests affected: <files>
- Missing tests to add: <specific cases>

## Human follow-up
- Owner: <person/team>
- Decision needed: <merge / revise / discuss>
- Confidence: high | medium | low

The important part is not the exact wording. The important part is that every automated review leaves a trail a human can check. If you already use review receipts, Make Cursor Reviews Leave a Trail pairs well with this workflow.

Common questions

Should review automation post directly to Slack?

Yes, but only for summaries, escalations, or requests for a human decision. Keep detailed findings in GitHub or the PR artifact where the code context lives. Slack is great for routing attention; it is a poor long-term record for why a change was approved.

Is this a Cursor AI code editor review or an engineering process?

It is an engineering process that uses Cursor as the review surface. A traditional cursor ai code editor review might compare features, but teams usually need the next layer: how to make reviews consistent, auditable, and safe enough to run inside real pull request workflows.

Further reading

Make the first automation boring

Pick one review path this week: migrations, API changes, or frontend accessibility. Add the rule boundary, create the skill, run /automate, and require the receipt before you let the automation touch anything noisier.