Generate a thorough, context-aware code review checklist tailored to your language, framework, and team standards that catches bugs, security issues, and maintainability problems before they reach production.
## ROLE You are a principal software engineer known for meticulous code reviews that catch critical bugs while remaining constructive and educational. You have reviewed thousands of pull requests across multiple languages and frameworks, and you have developed systematic approaches to code quality. ## OBJECTIVE Create a comprehensive, actionable code review checklist customized for a [LANGUAGE] codebase using [FRAMEWORK] in the domain of [PROJECT_DOMAIN]. The checklist should be usable by both the PR author (self-review) and reviewers, and it should scale from junior to senior engineers. ## TASK ### Section 1 — Correctness & Logic Generate checklist items for: - **Business Logic Verification:** Does the code correctly implement the requirements described in [TICKET_OR_SPEC]? Are all edge cases handled? What happens with empty inputs, null values, boundary conditions, and concurrent access? - **Error Handling:** Are all errors caught and handled appropriately? Are error messages user-friendly and debug-friendly? Is there proper distinction between recoverable and unrecoverable errors? - **State Management:** Are there race conditions? Is mutable state minimized? Are state transitions valid and complete? - **Data Validation:** Is all external input validated and sanitized? Are type coercions explicit? Are invariants enforced at the boundaries? ### Section 2 — Security Review Generate checklist items for: - **Injection Prevention:** SQL injection, XSS, command injection, LDAP injection — are all user inputs parameterized or escaped? - **Authentication & Authorization:** Are all endpoints properly authenticated? Is authorization checked at every layer (not just the UI)? Are there privilege escalation paths? - **Data Protection:** Are sensitive fields (PII, credentials, tokens) encrypted at rest and in transit? Are they excluded from logs and error messages? Is [COMPLIANCE_STANDARD] compliance maintained? - **Dependency Security:** Are there known vulnerabilities in new dependencies? Is the dependency minimal and from trusted sources? ### Section 3 — Performance & Scalability Generate checklist items for: - **Algorithmic Complexity:** Are there O(n²) or worse operations that could be optimized? Are there unnecessary iterations or redundant computations? - **Database Queries:** Are there N+1 query problems? Are indexes being used effectively? Are queries bounded with LIMIT? Are large result sets paginated? - **Resource Management:** Are connections, file handles, and memory properly released? Are there potential memory leaks? Are timeouts configured for external calls? - **Caching Opportunities:** Are there expensive computations or frequent reads that should be cached? Is cache invalidation correct? ### Section 4 — Maintainability & Readability Generate checklist items for: - **Naming Conventions:** Are variables, functions, and classes named clearly and consistently following [TEAM_CONVENTION] style? Do names convey intent? - **Code Structure:** Is the Single Responsibility Principle followed? Are functions and methods a reasonable length (under [MAX_FUNCTION_LENGTH] lines)? Is there unnecessary duplication? - **Comments & Documentation:** Are complex algorithms explained? Are public APIs documented? Are TODO comments tracked with ticket numbers? - **Test Coverage:** Are there unit tests for the happy path and edge cases? Are there integration tests for critical flows? Is test code itself clean and maintainable? Is coverage at or above [COVERAGE_THRESHOLD]%? ### Section 5 — Framework & Language Specific Generate checklist items specific to [LANGUAGE] and [FRAMEWORK]: - **Idiomatic Code:** Does the code follow language-specific best practices and idioms? - **Framework Patterns:** Are framework conventions followed (e.g., lifecycle hooks, middleware patterns, dependency injection)? - **Type Safety:** Are types used effectively? Are there any unsafe casts or type assertions that could be avoided? - **Configuration:** Are magic numbers extracted to constants? Are environment-specific values in configuration files? ## OUTPUT FORMAT Present the checklist as a markdown document with checkboxes (- [ ]) organized by section. Include severity labels (CRITICAL / HIGH / MEDIUM / LOW) for each item. Add a "Quick Review" version with only CRITICAL and HIGH items for time-constrained reviews.
Or press ⌘C to copy
Replace these placeholders with your own content before using the prompt.
[LANGUAGE][FRAMEWORK][PROJECT_DOMAIN][TICKET_OR_SPEC][COMPLIANCE_STANDARD][TEAM_CONVENTION][MAX_FUNCTION_LENGTH][COVERAGE_THRESHOLD]