Enable CodeRabbit auto-review on cuda-python (port CCCL's `.coderabbit.yaml`)

Summary

Enable CodeRabbit auto-review on cuda-python by adopting a config modeled on CCCL's .coderabbit.yaml (NVIDIA/cccl#8930). CodeRabbit is already installed on this repo but in opt-in mode (no .coderabbit.yaml in main; recent PRs show "Auto reviews are disabled on this repository... To trigger a single review, invoke the @coderabbitai review command").

CCCL is flipping auto-on with a config tuned to suppress the noise that caused us to keep auto-review off here. This issue proposes we port that config, adapted for cuda-python's layout and review culture.

Background: why we turned it off, and what's changed

CodeRabbit auto-review was previously disabled on cuda-python because the default profile was noisy: long walkthroughs, status/details panels, "poem" and "fortune" sections, AI-prompt blocks, finishing-touch suggestions (docstrings/unit tests/simplify), and pre-merge check comments on every PR. This made review threads hard to scan and crowded out human reviewers.

CCCL's new config (NVIDIA/cccl#8930, .coderabbit.yaml) addresses each of those failure modes explicitly. The relevant CCCL settings are below, with notes on what each one does and whether it should carry over to cuda-python unchanged.

CCCL config breakdown and cuda-python adaptation

Tone and profile (copy as-is)

profile: chill
tone_instructions: |
  Be direct, technical, brief. No praise, emojis, headings, or collapsible menus.
  Start each comment with one prefix:
  - suggestion: optional improvement;
  - important: must-fix/high-impact risk;
  - critical: blocking correctness/security/data-loss.

profile: chill is the lower-noise reviewer mode. The tone instructions constrain comment format and force a severity prefix so we can scan quickly. This is the single biggest noise-reduction lever and should copy over verbatim.

Walkthrough / status noise (copy as-is)

high_level_summary: true
high_level_summary_in_walkthrough: true
poem: false
in_progress_fortune: false
sequence_diagrams: false
estimate_code_review_effort: false
collapse_walkthrough: true
request_changes_workflow: false
review_status: false
review_details: false
enable_prompt_for_ai_agents: false

These remove the cosmetic and meta sections that drove most of the "CodeRabbit is loud" complaints. Keep all of these as CCCL has them.

Auto-review scope (adapt branch regex)

CCCL:

auto_review:
  enabled: true
  drafts: false
  base_branches:
    - "^main$"
    - "^branch/[0-9]+\\.[0-9]+\\.x$"
  ignore_usernames: ["copy-pr-bot", "dependabot[bot]", "github-actions[bot]", "nv-automation-bot"]

cuda-python adaptation:

• enabled: true, drafts: false — copy as-is.
• base_branches — CCCL's branch/X.Y.x pattern doesn't match our conventions. We should enumerate the active backport branches we care about (e.g. cuda-bindings 13.x, cuda-core release branches) or list the exact branch names. Proposal: start with ^main$ only, then add backport branches as they're cut.
• ignore_usernames — CCCL's list is a strong baseline. We should confirm whether nv-automation-bot and copy-pr-bot operate on cuda-python; if not, prune. Add any cuda-python-specific bots.

Tools (copy as-is)

tools:
  gitleaks: { enabled: true }
  markdownlint: { enabled: true }
  shellcheck: { enabled: true }

All three are appropriate for cuda-python (we have markdown docs, shell scripts under ci/, and gitleaks is cheap insurance).

Finishing touches (copy as-is)

finishing_touches:
  docstrings: { enabled: false }
  unit_tests: { enabled: false }
  simplify: { enabled: false }

These are the "auto-generate docstrings/tests/refactors" features. They produce drive-by suggestions that don't fit our review process. Disable.

Pre-merge checks (copy as-is)

pre_merge_checks:
  docstrings: { mode: "off" }
  title: { mode: "off" }
  description: { mode: "off" }
  issue_assessment: { mode: "off" }
  custom_checks: []

CCCL turns all of these off to keep the PR conversation focused on code. We should do the same.

Path instructions (replace wholesale)

CCCL's path_instructions cover libcudacxx, cudax, cub, thrust, c, and python/cuda_cccl. None of these paths exist in cuda-python. We need our own set, mapped to our top-level packages:

• cuda_bindings/**/* — focus on Cython binding correctness, ABI stability with the CUDA driver/runtime, error-code propagation, reference counting, GIL handling, NVRTC/nvJitLink coverage.
• cuda_core/**/* — focus on Pythonic API stability (we just shipped v1.0.0), stream ordering, lifetime/ownership of CUDA resources, CUDA Array Interface compatibility, host/device memory semantics, error translation.
• cuda_pathfinder/**/* — focus on path-resolution correctness across platforms, wheel/conda layouts, and behavior when the toolkit is missing or partial.
• cuda_python/**/* (the meta package) — focus on packaging correctness, dependency pins, and wheel/sdist surface.
• benchmarks/**/* — meaningful workloads, comparable axes, no excessive runtime.
• ci/**/* — matrix correctness, GPU-vs-CPU job split, artifact handling, clear failure modes.
• .github/**/* — permissions, event triggers, security boundaries.
• **/*.pyx, **/*.pxd — Cython-specific concerns: typed memoryviews, GIL/nogil correctness, exception specifications, fused types.

Concrete strings can be drafted in the PR; the principle is to keep comments narrowly scoped to high-impact concerns per area and let ruff/pre-commit handle style.

Knowledge base (replace file list)

CCCL points the knowledge base at AGENTS.md, CONTRIBUTING.md, and a dozen developer/docs pages. cuda-python's equivalents:

knowledge_base:
  opt_out: false
  code_guidelines:
    filePatterns:
      - "AGENTS.md"
      - "CONTRIBUTING.md"
      - "cuda_bindings/README.md"
      - "cuda_core/README.md"
      - "cuda_pathfinder/README.md"
      - "cuda_bindings/docs/source/release_notes.rst"  # if applicable
      - "cuda_core/docs/source/release_notes.rst"      # if applicable

AGENTS.md (~270 lines) and CONTRIBUTING.md are the highest-value context. Per-package READMEs and any developer/style docs should be added based on what we have. To be filled in during PR review.

Greptile coexistence

cuda-python currently has greptile.json in the repo root, so Greptile auto-reviews PRs today. CodeRabbit auto-detects other AI reviewers and explicitly says it "will avoid duplicating their findings... this may lead to a less comprehensive review." Running both auto means each does less work.

Options to discuss in this issue:

1. Run both auto; accept reduced coverage from each but get two independent perspectives. (Status quo + CodeRabbit on.)
2. Keep CodeRabbit auto + Greptile manual-trigger only.
3. Keep Greptile auto + CodeRabbit manual-trigger only (i.e. don't do this issue).
4. Drop one. Pick a primary.

Recommendation: start with option 1 for one to two weeks, measure noise and signal overlap on real PRs, then decide whether to consolidate.

Maintainer workflow

Mirror CCCL's docs/maintainers/coderabbit.rst into our maintainer docs so the team has a single reference for:

• @coderabbitai review / full review — manual trigger.
• @coderabbitai pause / resume — silence during heavy iteration.
• @coderabbitai ignore (in PR description) — opt a PR out entirely.
• @coderabbitai configuration — inspect resolved config on a PR.

Proposed rollout

1. Open a PR adding .coderabbit.yaml based on this proposal, with the path_instructions and knowledge_base sections filled in.
2. Land it on main only (not backport branches yet).
3. Watch the next ~10 PRs. If noise is acceptable, extend base_branches to active backport branches. If not, tune path_instructions or pause and revisit.
4. Add the maintainer doc.
5. Decide on Greptile coexistence after two weeks of data.

References

• CCCL enabling PR: NVIDIA/cccl#8930
• CCCL config: https://github.com/NVIDIA/cccl/blob/main/.coderabbit.yaml
• CCCL maintainer doc: https://github.com/NVIDIA/cccl/blob/main/docs/maintainers/coderabbit.rst
• Prior cuda-python discussion (Leo / Nader, Oct 27-28): #swcuda-python-tm
• cuda-python AGENTS.md: https://github.com/NVIDIA/cuda-python/blob/main/AGENTS.md

Comienza revisando la estructura propuesta de .coderabbit.yaml, el greptile.json existente, AGENTS.md y CONTRIBUTING.md. Compara la estructura del repositorio con las instrucciones de rutas y los archivos de la base de conocimiento propuestos, y después revisa la configuración y la documentación de mantenimiento de CCCL. Se considerará terminado cuando las decisiones del rollout, la configuración específica del repositorio y la documentación del flujo de trabajo de mantenimiento estén acordadas e implementadas.