Cursor Rules for Code Review: A Practical Template

Cursor rules for code review tell an assistant how to prioritize findings, what counts as sufficient evidence for a comment, and which project conventions to check. Without them, a review assistant produces long lists of style observations and misses the security gap in the middle. The quality of an AI review depends almost entirely on the quality of the criteria it works from. fenbs keeps the approved review criteria and the lessons from past reviews where the next assistant can read them before starting a review session.

This guide provides a working template and explains the principles behind each part.

What code review rules look like in Cursor

Code review rules for Cursor differ from general coding rules in one important way: they describe how to evaluate code rather than how to write it. They tell the assistant what to look for, how to classify what it finds, and how to communicate findings. A review rule that says "look for security issues" is not useful. One that says "flag any place user input reaches a database query without a parameterized query or an ORM method" is.

• Priority classification: what makes a finding a blocker, a suggestion, or a note.
• Evidence requirements: what the comment must include before it is posted.
• Security checks: the specific patterns to flag regardless of other findings.
• Project convention checks: which conventions this project enforces in review.
• What to skip: feedback that is out of scope for this review or for AI-assisted reviews.

Defect priority and evidence rules

A review that treats every finding as equally important is harder to act on than one that separates blockers from suggestions. A rule that defines priority categories gives the assistant a classification to apply to every finding. The evidence requirement prevents the assistant from raising a concern without explaining what it saw and why it matters.

# Code review rules

## Priority levels
BLOCKER — the change must not merge as-is. Use for:
  - Security vulnerabilities (injection, unvalidated input, exposed credentials, missing auth check).
  - Data loss or corruption risk.
  - Behavioral regressions against a known requirement.
  - Missing error handling for an error that silently corrupts state.

SUGGESTION — the change can merge; address in a follow-up. Use for:
  - Performance issues without immediate impact.
  - Missing test coverage for an edge case.
  - API design issues that do not yet affect callers.

NOTE — style, readability, or curiosity. Not required to address.

## Evidence requirement
Each BLOCKER comment must include:
  1. The exact line or lines involved.
  2. The specific risk or failure mode.
  3. A concrete example of how it could go wrong.
Do not raise a BLOCKER without all three. A vague "this looks insecure" is a NOTE, not a BLOCKER.

Security check rules

Security findings should be non-negotiable blockers, but only when there is actual evidence of the risk. Rules that list specific patterns to look for make the review more consistent than asking the assistant to "check for security issues" in general. OWASP Top 10 categories provide a reliable starting list.

# Security checks

Always check for the following regardless of the scope of the review:

## Injection
- SQL: user input in a query string without parameterization.
- Command: user input passed to exec, spawn, or eval.
- Template: user input rendered without escaping in a template or HTML response.

## Authentication and authorization
- A route or function that accepts a user ID from the request without verifying the caller owns it.
- A missing role or permission check before a privileged action.
- A token or session identifier logged or included in an error response.

## Secrets
- A credential, API key, or secret literal in source code.
- A secret passed as a URL query parameter (it will appear in logs).

## Input handling
- File uploads: missing file type check or path traversal risk in the stored filename.
- Redirects: a redirect destination taken from user input without validation.

Project convention checks

Every project has conventions that are not enforced by a linter: naming patterns, which libraries to use for certain tasks, which patterns are forbidden for historical reasons. These are the conventions most likely to be missed in a review because they require knowledge of the project's history. The review rule file is the right place to list them.

# Project convention checks

## Naming
- Service classes end in Service; repository classes end in Repository.
  Flag any new class that handles business logic but does not follow this pattern.
- Event names use past tense: OrderPlaced, PaymentFailed.

## Forbidden patterns
- Direct database calls outside of repository classes.
- `console.log` in production code (use the logger from src/lib/logger).
- Catching and swallowing errors with an empty catch block.
- Any new use of the deprecated parseUser() function (replaced by parseUserV2).

## Test requirements
- Every new public method on a service or repository needs at least one unit test.
- Tests that were skipped (xit, xdescribe) must have a tracking issue linked in the skip comment.

What to skip in a review

An AI review that comments on every possible improvement is not useful; it buries the important findings. Rules about what to skip are as important as rules about what to flag. Skip suggestions that are matters of taste when no project convention applies. Skip performance concerns that require profiling data you do not have. Skip architectural discussions that belong in a design review, not a code review. Code style should only appear when the project has a written convention for the pattern: a comment about naming that the project has not documented as a rule is a preference, not a finding.

A useful test for whether something belongs in a review comment: can the author act on it without more information? A comment that says "this function is too long" requires the author to decide what "too long" means and what to split. A comment that says "this function has three responsibilities; split out the validation logic" is actionable. AI-generated reviews fail the useful-comment test most often on style observations. A rule that says "do not raise style notes unless the project has a written convention for this pattern" removes a large category of low-value feedback automatically, leaving the review focused on changes that carry real risk or violate a settled team convention.

How to do this with fenbs

1. Create a free account and add the project you review code for.
2. Record the agreed review criteria as a skill or a standing rule in fenbs. Include the priority levels, the evidence requirement, and the security patterns your team always checks.
3. After each review cycle, add a lesson for any category of issue that appeared more than once. Note the pattern and what the fix was. Recurring mistakes are the best source of review rules.
4. Connect Cursor to fenbs over MCP from Integrations. Ask it to read the project context, including rules and lessons, before starting a review session.
5. When a convention changes or a deprecated pattern is finally removed, update both the fenbs rule and the Cursor rule file. Outdated review criteria produce false positives that erode trust in the review.

For the broader comparison of AI review tools, see the AI code review tools guide. For the review process itself, the code review best practices guide covers the human side.