-
Notifications
You must be signed in to change notification settings - Fork 4
Expand file tree
/
Copy path.coderabbit.yaml
More file actions
87 lines (70 loc) · 4.47 KB
/
.coderabbit.yaml
File metadata and controls
87 lines (70 loc) · 4.47 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
reviews:
profile: assertive
request_changes_workflow: true
high_level_summary: true
auto_title_placeholder: "@coderabbitai"
path_filters:
- "!node_modules/**"
- "!dist/**"
- "!generated/**"
tools:
eslint:
enabled: true
path_instructions:
- path: "backend/**/*.{ts,js}"
instructions: |
You are reviewing a Node.js + TypeScript + Express + Prisma backend in an MVP development workflow.
ONLY flag issues that fall into one of these HIGH-IMPACT categories:
1. Security vulnerabilities (hardcoded secrets, API keys, tokens, credentials, input injection risks, sensitive data exposure)
2. Incorrect logic or data handling (wrong business logic, data corruption risk, incorrect query behavior)
3. Crashes or runtime failures (unhandled promise rejections, missing error handling, blocking sync ops on critical paths)
4. Breaking functionality (broken imports after build, ESM/CJS incompatibility, missing env vars that will crash at startup)
DO NOT comment on:
- Code style or formatting
- Naming conventions or variable/function names
- Minor optimizations or performance improvements that don't affect correctness
- Refactoring suggestions or code organization preferences
- Non-blocking best practices or "nice to have" improvements
- Dead code, unused imports, or commented-out code (unless it exposes secrets)
- Logging library preferences (only flag if secrets are logged)
- Prisma patterns unless they cause incorrect results or crashes (e.g. silent data loss, N+1 causing timeout in production)
Be concise. One short sentence per issue. No explanations of why best practices exist.
MUST request changes if:
- Hardcoded secret, token, API key, or credential is found
- Security vulnerability that can be exploited
- Unhandled async error that will crash the process
- path: "frontend/src/**/*.{ts,tsx,js,jsx}"
instructions: |
You are reviewing a React 19 + TypeScript + Tailwind CSS frontend in an MVP development workflow.
ONLY flag issues that fall into one of these HIGH-IMPACT categories:
1. Security vulnerabilities (hardcoded secrets, tokens, XSS risks via dangerouslySetInnerHTML, exposed credentials)
2. Broken or incorrect React behavior (missing keys causing state corruption, infinite render loops, stale closures causing incorrect data, missing dependencies in useEffect that cause bugs)
3. Runtime crashes (calling methods on null/undefined, missing required props that will throw, unhandled promise rejections in async handlers)
4. Incorrect TypeScript that hides real bugs (unsafe type assertions that bypass null checks, incorrect prop types that will cause runtime errors)
DO NOT comment on:
- Code style or formatting
- Component naming or file organization
- Tailwind class order or style preferences
- Accessibility improvements (unless it causes a crash)
- Refactoring, component decomposition, or "cleaner" patterns
- Minor optimizations (memoization, avoiding re-renders unless severe)
- Using inline styles vs utility classes
- Non-blocking best practices
Be concise. One short sentence per issue. No explanations of why best practices exist.
MUST request changes if:
- Hardcoded secret, token, or API key is found in frontend code
- Security vulnerability that can be exploited (e.g. XSS)
- path: "backend/prisma/**/*.prisma"
instructions: |
You are reviewing a Prisma schema in an MVP development workflow.
ONLY flag issues that fall into one of these HIGH-IMPACT categories:
1. Missing indexes on foreign keys or fields used in WHERE/ORDER BY that will cause severe query performance issues at scale
2. Cascade delete behavior that could silently wipe critical data
3. Schema changes that are backwards-incompatible and will break the running application (e.g. non-nullable field added without default)
4. Ambiguous nullable fields where null vs missing has different semantics and could cause data bugs
DO NOT comment on:
- Naming conventions for models or fields
- Minor style preferences in schema formatting
- Suggested indexes that are "nice to have" but not critical
- Refactoring or restructuring suggestions
Be concise. One short sentence per issue.