You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# Enable experimental features (currently not using any specific early_access features)
8
+
early_access: true
9
+
10
+
chat:
11
+
# CodeRabbit will automatically respond to @coderabbitai mentions in PR comments
12
+
auto_reply: true
13
+
14
+
issue_enrichment:
15
+
labeling:
16
+
auto_apply_labels: true
17
+
labeling_instructions:
18
+
- label: bug
19
+
instructions: Issues reporting bugs, errors, crashes, incorrect behavior, or unexpected results. This includes runtime errors, logic errors, broken functionality, regressions, and any deviation from expected or documented behavior.
20
+
- label: enhancement
21
+
instructions: Feature requests, improvements to existing functionality, performance optimizations, refactoring suggestions, UI/UX enhancements, and any suggestions to make the project better or add new capabilities.
22
+
- label: documentation
23
+
instructions: Documentation updates, additions, corrections, or clarifications needed. This includes missing docs, outdated information, unclear instructions, API documentation, code examples, README improvements, and any requests for better explanations or guides.
24
+
planning:
25
+
enabled: true
26
+
auto_planning:
27
+
enabled: true
28
+
labels:
29
+
- "plan-me"# Auto-plan issues with this label
30
+
- "feature"# Also auto-plan these
31
+
- "!no-plan"# Never auto-plan issues with this label
32
+
33
+
reviews:
34
+
profile: assertive # Options: chill (focuses on significant issues, less nitpicky about style), assertive (more thorough, flags style issues and minor improvements too)
35
+
36
+
auto_review:
37
+
# Automatically trigger reviews when PRs are opened or updated
38
+
enabled: true
39
+
# Skip auto-review if PR title contains these keywords
40
+
ignore_title_keywords:
41
+
- "WIP"
42
+
# Don't auto-review draft PRs
43
+
drafts: false
44
+
# Only auto-review PRs targeting these branches
45
+
base_branches:
46
+
- main
47
+
- develop
48
+
49
+
# Include a high-level summary at the start of each review
50
+
high_level_summary: true
51
+
52
+
# Generate sequence diagrams for complex code flows
53
+
sequence_diagrams: true
54
+
55
+
# Include poems in reviews
56
+
poem: true
57
+
58
+
# Show review completion status
59
+
review_status: true
60
+
61
+
# Keep the walkthrough section expanded by default
62
+
collapse_walkthrough: false
63
+
64
+
# Include summary of all changed files
65
+
changed_files_summary: true
66
+
67
+
# Automatically request changes on the PR (just leave comments)
68
+
request_changes_workflow: true
69
+
70
+
# Pre-merge checks to enforce before merging PRs
71
+
pre_merge_checks:
72
+
description:
73
+
# Validate that PR has a proper description
74
+
mode: warning # Options: off, warning, error
75
+
docstrings:
76
+
# Disable docstring coverage checks (let's assume we don't need them)
77
+
mode: off
78
+
79
+
# Exclude these paths from reviews (build artifacts and dependencies)
80
+
path_filters:
81
+
- "!**/node_modules/**"# npm dependencies
82
+
- "!**/android/**"# Native Android build files
83
+
- "!**/ios/**"# Native iOS build files
84
+
- "!**/.expo/**"# Expo build cache
85
+
- "!**/.expo-shared/**"# Expo shared config
86
+
- "!**/dist/**"# Build output
87
+
88
+
# Use the following tools when reviewing
89
+
tools:
90
+
shellcheck:
91
+
enabled: true
92
+
ruff:
93
+
enabled: true
94
+
markdownlint:
95
+
enabled: true
96
+
github-checks:
97
+
enabled: true
98
+
timeout_ms: 90000
99
+
languagetool:
100
+
enabled: true
101
+
enabled_only: false
102
+
level: default
103
+
biome:
104
+
enabled: true
105
+
hadolint:
106
+
enabled: true
107
+
swiftlint:
108
+
enabled: true
109
+
phpstan:
110
+
enabled: true
111
+
level: default
112
+
golangci-lint:
113
+
enabled: true
114
+
yamllint:
115
+
enabled: true
116
+
gitleaks:
117
+
enabled: true
118
+
checkov:
119
+
enabled: true
120
+
detekt:
121
+
enabled: true
122
+
eslint:
123
+
enabled: true
124
+
125
+
# Apply the following labels to PRs
126
+
labeling_instructions:
127
+
- label: Python Lang
128
+
instructions: Apply when the PR/MR contains changes to python source-code
129
+
- label: Solidity Lang
130
+
instructions: Apply when the PR/MR contains changes to solidity source-code
131
+
- label: Typescript Lang
132
+
instructions: Apply when the PR/MR contains changes to javascript or typescript source-code
133
+
- label: Ergoscript Lang
134
+
instructions: Apply when the PR/MR contains changes to ergoscript source-code
135
+
- label: Bash Lang
136
+
instructions: >-
137
+
Apply when the PR/MR contains changes to shell-scripts or BASH code
138
+
snippets
139
+
- label: Make Lang
140
+
instructions: >-
141
+
Apply when the PR/MR contains changes to the file `Makefile` or makefile
142
+
code snippets
143
+
- label: Documentation
144
+
instructions: >-
145
+
Apply whenever project documentation (namely markdown source-code) is
146
+
updated by the PR/MR
147
+
- label: Linter
148
+
instructions: >-
149
+
Apply when the purpose of the PR/MR is related to fixing the feedback
150
+
from a linter
151
+
# Review instructions that apply to all files
152
+
instructions: >-
153
+
- Verify that documentation and comments are free of spelling mistakes
154
+
- Ensure that test code is automated, comprehensive, and follows testing best practices
155
+
- Verify that all critical functionality is covered by tests
156
+
- Confirm that the code meets the project's requirements and objectives
157
+
- Confirm that copyright years are up-to date whenever a file is changed
158
+
- Point out redundant obvious comments that do not add clarity to the code
159
+
- Ensure that comments are concise and suggest more concise comment statements if possible
160
+
- Discourage usage of verbose comment styles such as NatSpec
161
+
- Look for code duplication
162
+
- Suggest code completions when:
163
+
- seeing a TODO comment
164
+
- seeing a FIXME comment
165
+
# Custom review instructions for specific file patterns
166
+
path_instructions:
167
+
# TypeScript/JavaScript files
168
+
- path: "**/*.{ts,tsx,js,jsx}"
169
+
instructions: |
170
+
NextJS:
171
+
- Ensure that "use client" is being used
172
+
- Ensure that only features that allow pure client-side rendering are used
173
+
- NextJS best practices (including file structure, API routes, and static generation methods) are used.
174
+
175
+
TypeScript:
176
+
- Avoid 'any', use explicit types
177
+
- Prefer 'import type' for type imports
178
+
- Review for significant deviations from Google JavaScript style guide. Minor style issues are not a priority
179
+
- The code adheres to best practices associated with React
180
+
- The code adheres to best practices associated with React PWA
181
+
- The code adheres to best practices associated with SPA
182
+
- The code adheres to best practices recommended by lighthouse or similar tools for performance
183
+
- The code adheres to best practices associated with Node.js
184
+
- The code adheres to best practices recommended for performance
185
+
Security:
186
+
- No exposed API keys or sensitive data
187
+
- Use expo-secure-store for sensitive storage
188
+
- Validate deep linking configurations
189
+
- Check for common security vulnerabilities such as:
190
+
- SQL Injection
191
+
- XSS (Cross-Site Scripting)
192
+
- CSRF (Cross-Site Request Forgery)
193
+
- Insecure dependencies
194
+
- Sensitive data exposure
195
+
Internationalization:
196
+
- User-visible strings should be externalized to resource files (i18n)
197
+
# HTML files
198
+
- path: "**/*.html"
199
+
instructions: |
200
+
Review the HTML code against the google html style guide and point out any mismatches. Ensure that:
201
+
- The code adheres to best practices recommended by lighthouse or similar tools for performance
202
+
# CSS files
203
+
- path: "**/*.css"
204
+
instructions: |
205
+
Review the CSS code against the google css style guide and point out any mismatches. Ensure that:
206
+
- The code adheres to best practices associated with CSS.
207
+
- The code adheres to best practices recommended by lighthouse or similar tools for performance.
208
+
- The code adheres to similar naming conventions for classes, ids.
209
+
# Python files
210
+
- path: "**/*.{py}"
211
+
instructions: |
212
+
Python:
213
+
- Check for major PEP 8 violations and Python best practices.
214
+
# Solidity Smart Contract files
215
+
- path: "**/*.sol"
216
+
instructions: |
217
+
Solidity:
218
+
- Review the Solidity contracts for security vulnerabilities and adherence to best practices.
219
+
- Ensure immutability is used appropriately (e.g., `immutable` and `constant` where applicable).
220
+
- Ensure there are no unbounded loops that could lead to gas exhaustion.
221
+
- Verify correct and explicit visibility modifiers for all state variables and functions.
222
+
- Flag variables that are declared but used only once or are unnecessary.
223
+
- Identify potential gas optimization opportunities without compromising readability or security.
224
+
- Verify that any modification to contract logic includes corresponding updates to automated tests.
225
+
- Ensure failure paths and revert scenarios are explicitly handled and validated.
226
+
- Validate proper access control enforcement (e.g., Ownable, RBAC, role checks).
227
+
- Ensure consistent and correct event emission for all state-changing operations.
228
+
- Confirm architectural consistency with existing contracts (no unintended storage layout changes unless clearly documented).
229
+
- Flag major feature additions or architectural changes that were implemented without prior design discussion (if applicable).
230
+
- Flag pull requests that mix unrelated changes or multiple concerns in a single submission.
231
+
- Ensure security-sensitive logic changes are not introduced without adequate test coverage.
232
+
- Review for common smart contract vulnerabilities, including but not limited to:
233
+
- Reentrancy
234
+
- Improper input validation
235
+
- Access control bypass
236
+
- Integer overflows/underflows (if using unchecked blocks)
237
+
- Front-running risks where applicable
238
+
# Javascript/Typescript test files
239
+
- path: "**/*.test.{ts,tsx,js,jsx}"
240
+
instructions: |
241
+
Review test files for:
242
+
- Comprehensive coverage of component behavior
243
+
- Proper use of @testing-library/react-native
244
+
- Async behavior is properly tested
245
+
- Accessibility testing is included
246
+
- Test descriptions are sufficiently detailed to clarify the purpose of each test
247
+
- The tests are not tautological
248
+
# Solidity test files
249
+
- path: "**/*.test.{sol}"
250
+
instructions: |
251
+
Review test files for:
252
+
- Comprehensive coverage of contract behavior.
253
+
- Coverage of success paths, edge cases, and failure/revert scenarios.
254
+
- Proper validation of access control restrictions.
255
+
- Verification of event emissions where applicable.
256
+
- Explicit validation of state changes after each relevant function call.
257
+
- Adequate test updates whenever contract logic is modified.
258
+
- Deterministic behavior (tests should not rely on implicit execution order or shared mutable state).
259
+
- Clear and descriptive test names that reflect the intended behavior being validated.
260
+
# Asset files (images, fonts, etc.)
261
+
- path: "assets/**/*"
262
+
instructions: |
263
+
Review asset files for:
264
+
- Image optimization (appropriate size and format)
265
+
- Proper @2x and @3x variants for different screen densities
0 commit comments