CodeRabbit PR Review

This skill scaffolds and tunes a production-grade CodeRabbit configuration so the AI reviewer comments on the right files, with the right tone, using the linters you actually run. It is for teams that want CodeRabbit's PR feedback to match house style instead of firing generic nitpicks on every diff — backend leads, platform teams, and anyone tired of noisy bot reviews.

When to use it

• You just enabled CodeRabbit on a repo and want a .coderabbit.yaml that respects your monorepo layout.
• The bot keeps flagging generated code, lockfiles, or vendored directories you don't review.
• Different parts of the codebase need different rules (strict on src/payments/**, relaxed on scripts).
• You want CodeRabbit to enforce conventions it doesn't know about ("require a changeset", "no console.log in prod code").
• You're standardizing review behavior across many repos and need a reusable config baseline.

How it works

Everything is driven by a .coderabbit.yaml at the repo root, validated against CodeRabbit's published schema. The skill helps you set:

• reviews.profile — chill (fewer, higher-signal comments) or assertive (thorough, more pedantic).
• reviews.path_filters — glob include/exclude (!dist/**, !**/*.lock) controlling what gets reviewed at all.
• reviews.path_instructions — per-glob natural-language rules CodeRabbit applies as review criteria.
• reviews.tools — toggles for the integrated linters: ast-grep, ruff, eslint, gitleaks, semgrep, markdownlint, and more.
• reviews.auto_review and request_changes_workflow for gating behavior.

It also covers in-PR comment commands and learnings — corrections you leave on reviews that CodeRabbit remembers across future PRs.

Usage

curl -fsSL --create-dirs -o ~/.claude/skills/coderabbit-pr-review/SKILL.md https://claudeskil.com/skills/coderabbit-pr-review/SKILL.md

# .coderabbit.yaml
language: en-US
reviews:
  profile: chill
  request_changes_workflow: true
  auto_review:
    enabled: true
    drafts: false
  path_filters:
    - "!**/*.lock"
    - "!**/dist/**"
    - "!**/__generated__/**"
  path_instructions:
    - path: "src/payments/**"
      instructions: "Flag any unrounded float math on money. Require idempotency keys on external calls."
    - path: "**/*.test.ts"
      instructions: "Do not flag long describe blocks or magic numbers in fixtures."
  tools:
    ruff: { enabled: true }
    gitleaks: { enabled: true }
    ast-grep: { enabled: true }

Then on any PR:

@coderabbitai review            # re-run the review
@coderabbitai generate docstrings
@coderabbitai resolve           # resolve all its threads
@coderabbitai configuration     # dump the effective config

Tips & gotchas

• path_filters exclusions use ! prefixes and are evaluated in order — put broad excludes before narrow includes.
• path_instructions are advisory to the model, not hard rules; keep each one short and imperative for reliable adherence.
• Replying to a comment with a correction creates a learning scoped to that repo — review @coderabbitai learnings periodically; stale ones cause confusing feedback.
• profile: assertive plus auto_review on a busy repo generates a lot of comments; start with chill.
• The config in a PR's source branch is what applies to that PR, so test config changes by opening a PR with them.

FAQ

Does CodeRabbit run my linters or its own? It runs the integrated tools (ruff, eslint, gitleaks, semgrep, ast-grep, etc.) inside its sandbox and folds their findings into the review — you don't need them in CI for CodeRabbit to use them.

How do I stop reviews on a specific PR? Comment @coderabbitai pause, or exclude the branch/paths via config; @coderabbitai resume re-enables.

Where do learnings live? They're stored per-repository and surface automatically; ask @coderabbitai to list them, and delete ones that no longer reflect your standards.