review-checklists

<skill_overview> Ensure no critical aspects are missed during code review by providing domain-specific checklists. Performing the "Deep Pass" or "Test Review" steps of the review process. </skill_overview>

<checklist_security> Input Validation: Are all inputs (API, user, file) validated and sanitized? Authentication/Authorization: Are sensitive endpoints protected? Are permission checks correct? Secrets: Are any keys, tokens, or passwords hardcoded? (Check logs too!) Data Exposure: Is sensitive data (PII) accidentally returned in API responses? Dependencies: Are new dependencies necessary and trustworthy? </checklist_security>

<checklist_performance> Database: Check for N+1 queries, missing indexes, or selecting unnecessary columns (SELECT *). Loops: Avoid expensive operations (I/O, DB calls) inside loops. Memory: Check for large object allocations or memory leaks (e.g., unclosed streams/listeners). Async: Are promises handled correctly? Is await used sequentially when parallel Promise.all would work? Frontend: Check for unnecessary re-renders or large bundle additions. </checklist_performance>

<checklist_reliability_logic> Error Handling: Are errors caught? Are they logged with context? Is the user experience graceful on failure? Null/Undefined: Check for potential null pointer exceptions or undefined access. Concurrency: Check for race conditions in shared state. State Management: Is state mutation predictable? Edge Cases: Empty arrays, zero values, max values, negative numbers, special characters. </checklist_reliability_logic>

<checklist_testing> Existence: Is there a corresponding test for the new code? Coverage: Do tests cover the happy path, error paths, and edge cases? Independence: Do tests rely on external state or execution order? Assertions: Are assertions specific? (Avoid assert(true) or weak checks). Readability: Are tests easy to understand? Do they document the behavior? </checklist_testing>

<checklist_maintainability> Naming: Do names reveal intent? (e.g., isUserActive vs status). Complexity: Can functions be simplified or broken down? Duplication: Is code copy-pasted? Can it be refactored into a utility? Comments: Do comments explain why, not what? Are TODOs actionable? Configuration: Are magic numbers/strings extracted to constants or config? </checklist_maintainability>

<language_specific_pointers> <important_rule> When reviewing code in a specific language or framework, ensure you are familiar with its conventions and best practices. If available, use specialized knowledge sources or skills for that technology stack. </important_rule> </language_specific_pointers>