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
Do not aim for code style, this is already handled by the linter. Unless the code style suggestion is objectively better, do not suggest changes.
34
+
Ensure Self-Documenting Code: Aim to make your code self-explanatory through clear naming and structure.
35
+
The less time a developer has to spend understanding the code, the better but without being overly verbose on the namings.
36
+
Follow the YAGNI Principle: 'You aren't gonna need it' is a principle that prevents developers from
37
+
adding functionality until it is necessary. This can help keep your codebase lean and simple.
38
+
Externalizing User-visible Strings: Ensuring all user-facing texts (such as error messages, API responses, and
39
+
notification content) are sourced from external resource files or constants where reasonable. This makes it
40
+
easier to update or translate them without having to modify business logic.
41
+
Avoiding Concatenation of Translated Strings: Concatenation might change the meaning of a sentence
42
+
when it is translated to another language due to differences in grammar or sentence structure. Instead,
43
+
use templates or positional parameters.
44
+
45
+
- path: '**/src/**'
46
+
instructions: |
47
+
Review the following code written using Fastify and TypeScript for a backend API, ensuring:
48
+
- The code adheres to best practices associated with Fastify (plugins, decorators, hooks, schema validation) and idiomatic Node.js.
49
+
- Input validation and serialization use schemas (e.g. Zod or JSON Schema) rather than manual checks scattered through handlers.
50
+
- The code is well-structured and easy to read. The reader must be able to understand the code without having to refer to other parts of the codebase.
51
+
- The code is modular and reusable. Services, repositories, and utilities should be designed to be reusable across routes.
52
+
- The dev-facing API (exported functions, plugin options, service methods) is flexible while offering a good developer experience.
53
+
- Exported functions, types, and plugin contracts should be documented with JSDoc comments where non-obvious.
54
+
- Existing JSDocs should be descriptive, direct but clear, and concise.
55
+
- The internal API should be consistent, predictable, easy to use and resilient to changes.
56
+
- The code must be performant on Node.js: avoid blocking the event loop (e.g. synchronous I/O, heavy CPU work in the request path), and avoid unnecessary await chaining or sequential awaits that could run concurrently.
57
+
- The code should be memory efficient and avoid memory leaks, especially in long-running processes (unclosed connections, growing caches, dangling event listeners, unbounded queues).
58
+
- Async errors are handled explicitly: async route handlers, Prisma calls, and external API calls should have proper try/catch or be wrapped so failures produce a controlled error response instead of an unhandled rejection.
59
+
- Sensitive data (passwords, tokens, secrets, PII) is never logged or returned in API responses.
60
+
- Database access (Prisma) is not duplicated ad hoc in multiple places; prefer a shared data-access layer.
61
+
- Prefer composition over inheritance. Composition provides better flexibility over inheritance. Avoid deep inheritance trees.
62
+
- Create reusable type definitions: If the same type structure is used in multiple places, create a type definition for it.
63
+
- If you observe overly repeated code (more than 2~3 times), create a new function. If a function becomes too complex, decompose it into smaller ones.
64
+
- Don't be too critical about the code architecture itself, like whether the indentation is right or wrong, or the order of things. That doesn't really make sense to flag.
65
+
- Don't judge integration code with external tools/SDKs (e.g. Supabase, OpenTelemetry, Resend, OpenAI) against their internal implementation - assume their documented usage patterns are correct.
66
+
67
+
- path: '**/prisma/**'
68
+
instructions: |
69
+
Review Prisma schema and migration-related code ensuring:
70
+
- Schema changes are backward compatible where possible, or clearly flagged as breaking (e.g. dropping/renaming columns with existing data).
71
+
- New required fields either have a default value or the migration accounts for existing rows.
72
+
- Indexes are added for columns used in frequent lookups or foreign keys.
73
+
- Do not flag migration SQL files themselves for style; they are generated and should not be hand-edited except for documented hotfixes.
0 commit comments