chore: point CodeRabbit at this repository's own conventions - #402
Conversation
A `.coderabbit.yaml` whose `path_instructions` name the spec file rather than restating it, so there is one copy of the rules and it is the one already under review. The `path_filters` keep generated output and the lockfile out of the diff it reads.
|
Warning Review limit reachedNext included review available in 35 minutes. View limit detailsLimit details: You’ve used all 10 included reviews currently available. Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. Review configuration: ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 10 included reviews per hour; 4 remain after this review. 📝 WalkthroughWalkthroughThe pull request adds ChangesCodeRabbit Configuration
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This change only adds repository-specific review guidance and excludes generated files and the lockfile; no actionable merge-blocking risk remains beyond normal checks and review. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (1 skipped: 1 unsupported.) ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
CodeRabbit auto-detects them as code guidelines. Naming them in `path_instructions` tells it to REVIEW those files rather than USE them, which is the opposite of what the entry was for — and it made the rest of the instructions redundant, since auto-detection was already loading the spec. The claim check the entry existed for moves onto the code's own glob, where it belongs: when a diff changes the spec alongside the code, hold the spec to the code.
Every `path_filter` except the lockfile named a path git already ignores — `src/generated/**`, `.vitepress/dist/**`, `.vitepress/cache/**` — so none of them could ever appear in a diff for CodeRabbit to filter. Checked with `git ls-files` across all seven repositories: zero tracked files behind any of them. `pnpm-lock.yaml` is the one that is tracked, and the one worth filtering.
1 participant
Adds a
.coderabbit.yamlnow that CodeRabbit is installed on the org.It points at this repository's spec rather than restating it. The
conventions are already written down and already reviewed; a second copy in
YAML would be a fifth copy with no gate, which is the drift this org keeps
meeting. So
path_instructionssay read the spec file, hold the diff to it,and spell out only the handful of things a generic reviewer gets actively
wrong — the ones where a suggestion is not debatable but simply not how this
codebase works.
path_filterskeep generated output and the lockfile out of what it reads.Nothing else is configured. Every other key stays at its default, deliberately:
profile: chill, nopoem, norequest_changes_workflow, notoolsblock —the linters CodeRabbit runs are the ones whose config it finds, and this repo's
gate already runs them in CI.
Two knobs worth knowing about rather than setting blind:
reviews.profile: assertiveraises the nitpick volume. Worth trying oncethere is a review or two to judge it against.
reviews.request_changes_workflow: truemakes CodeRabbit block a PR untilits comments are resolved. Off by default, and it should probably stay off
until the instructions have been tuned.
The GitHub App install itself is a click in the CodeRabbit dashboard — this file
does nothing until the app can see the repository.
Summary by CodeRabbit