Docs

Review rules

Review rules let you tell Codzee what your team cares about, in plain English, on top of its normal review. This page shows how to write them, with examples.

What review rules are

A review rule is one sentence, such as “Every API route calls requireAuth() before reading the request”. Codzee checks each pull request against your rules and leaves a labelled comment when one is broken. There are four kinds of rules:

KindExampleStatus
Team conventions“Use logger from src/lib/log, never console.log”Available
Focus / ignore guidance“Be extra strict on input validation in src/payments/**”, “Don’t comment on style in legacy/**”Available
Blocking checks“Every migration has a down() rollback” → the PR check turns redComing soon
Existing docsReuse AGENTS.md, CLAUDE.md, .cursorrules, CONTRIBUTING.md, docs/*guidelines*.mdComing soon

Add a rule

  1. Open Settings → Review rules.
  2. Pick a template, or choose + Add rule to write your own.
  3. Fill in the three fields below and save.
  • Rule: write it like you’d tell a new teammate, one rule per box. Example: API handlers must validate request bodies with zod
  • Applies to (optional, empty = all files): example src/api/**. Separate several patterns with commas. Other examples: **/*.sql, migrations/**, !**/*.test.ts
  • Severity: Suggestion or Important (default). Blocking is coming soon.

Rule text is tidied up when you save: extra spaces and line breaks become single spaces, and a rule can be 1 to 500 characters.

Writing rules that work

Name the exact thing to check: which function, file or pattern.

✅ Clear: Codzee can check it❌ Unclear: too vague to check
“Use logger from src/lib/log, never console.log”“Write clean code”
“Every API route calls requireAuth() before reading the request”“Make it secure”
“Prices are stored in cents as integers, never floats”“Be careful with money”
“React components in components/ use named exports”“Follow our conventions”
“Don’t comment on code in legacy/”“Ignore boring stuff”

Applies to: path patterns

Leave it empty and the rule applies to every file. Otherwise a file matches if it matches at least one normal pattern (or there are none) and no ! pattern.

PatternMatches
src/api/**every file under src/api/
**/*.sqlevery SQL file anywhere
migrations/**everything in migrations/
src/**/*.tsxReact files under src/
!**/*.test.tsexcludes test files (on its own: all files except tests)
legacyno * or ?, so it matches that exact path or anything under it, e.g. legacy/old.js

Combine patterns with commas, for example src/**, !src/db/** means everything under src/ except src/db/. Up to 10 patterns per rule.

Severity

  • Suggestion: a light comment; fine to ignore.
  • Important: a normal review comment (the default).
  • Blocking: fails the Codzee check until fixed. Coming soon. Until then, blocking templates are added as Important.

Focus and ignore rules

Ordinary rules whose text steers the review:

  • “Be extra strict on input validation in src/payments/**” (important)
  • “Don’t comment on style or naming in legacy/**” (suggestion)
  • “Ignore generated files in src/gen/**” (suggestion)

Org-wide and repo rules

When you create a rule you choose whether it applies to all repositories or to one repository. In a repository’s view, an org-wide rule has one switch, On for this repo. Turn it off and the rule stops applying to that repository only. For example, the org rule “Use logger, never console.log” can be Off for this repo on acme/legacy-cli while staying on everywhere else.

A repository’s own rules come first. If one disagrees with an org-wide rule, Codzee follows the repository’s rule. For example, with the org rule “Use logger, never console.log” and the acme/tools rule “console.log is fine in scripts/”, Codzee won’t flag console.log in acme/tools/scripts/.

What you’ll see on the PR

A comment from a broken rule keeps Codzee’s usual label (what kind of problem and how serious) and adds the rule that triggered it, so a serious bug that also breaks a rule still reads as serious:

🔶 Bug | Major · ⚠️ Team rule: “API handlers must validate request bodies with zod”

createOrder reads req.body.items without a zod schema. Add OrderSchema.parse(req.body) before using it.

Rule set in Codzee settings · Manage rules

Suggestion rules use a 💡 instead of the ⚠️. The review summary adds one line, for example:

Checked against 6 team rules: 2 comments.

Limits

PlanEnabled rules
Trial10
Starter10
Team50
EnterpriseUnlimited

At the limit, “Add rule” is disabled and the page says “10 of 10 rules on Starter.” with a link to move to Team for up to 50 rules. If you are over the limit at review time, the extra rules are skipped and the summary says so: “2 rules skipped — your plan includes 10.” A repository’s own rules are kept first, then important rules before suggestions, then the oldest.

Coming next

Rules in your repo. Put a .codzee.md file in the repo root. Codzee reads it from the pull request’s base branch, so a PR cannot loosen its own rules. Only bullets under a ## Rules heading count; everything else is ignored.

# Codzee rules for acme/api

## Rules
- API handlers must validate request bodies with zod (src/api/**) [important]
- Every migration needs a down() rollback (migrations/**) [blocking]
- Use our logger, never console.log
- Don't comment on naming in legacy code (legacy/**) [suggestion]
- Prices are integers in cents, never floats (src/billing/**, src/orders/**)

Blocking rules. Mark a rule [blocking] and a broken rule turns the Codzee check red until it is fixed. You can then require that check in GitHub branch protection to block merges.

Review rules | Codzee | Codzee