kazdenc Review code across five dimensions and produce a prioritized list of findings. Suggest improvements; don't demand them. Praise good patterns alongside issues.
Step 1: Read the Code
Understand intent before judging implementation. Before writing a single finding:
- Identify the purpose of the change (feature, fix, refactor, test).
- Note the architectural context (framework, patterns, conventions in use).
- Read related tests and documentation if available.
- If reviewing a PR, read the description and linked issues first.
Step 2: Review Across Five Dimensions
Evaluate the code against each dimension using the specific checks below.
Correctness
| Check | What to look for |
|---|---|
| Logic errors | Incorrect conditionals, wrong operator precedence, inverted boolean logic |
| Off-by-one | Fence-post errors in loops, slices, pagination, boundary conditions |
| Null / undefined handling | Missing optional chaining, unchecked nullable returns, empty-array assumptions |
| Race conditions | Shared mutable state, unguarded async sequences, stale closures |
| Error paths | Swallowed exceptions, missing try/catch, unhelpful error messages, no fallback |
| Edge cases | Empty inputs, very large inputs, unicode, negative numbers, timezone boundaries |
Readability
| Check | What to look for |
|---|---|
| Naming | Ambiguous variable names, misleading function names, inconsistent conventions |
| Function length | Functions doing more than one thing, > 40 lines is a smell |
| Nesting depth | More than 3 levels of nesting; consider early returns or extraction |
| Comments | Missing "why" comments on non-obvious logic; remove comments that restate code |
| Consistency | Style deviations from the rest of the codebase |
| Cognitive load | Complex ternaries, implicit type coercion, magic numbers or strings |
Performance
| Check | What to look for |
|---|---|
| Unnecessary re-renders | Missing memoization, inline object/function creation in render path |
| N+1 queries | Database calls inside loops, unbatched API requests |
| Missing memoization | Expensive computations recalculated on every render or call |
| Large bundles | Heavy imports that could be lazy-loaded or replaced with lighter alternatives |
| Algorithmic complexity | O(n^2) or worse where O(n) or O(n log n) is achievable |
| Memory leaks | Uncleared intervals/timeouts, missing event listener cleanup, growing caches |
Security
| Check | What to look for |
|---|---|
| Injection | Unsanitized user input in SQL, shell commands, templates, or regex |
| XSS | Unescaped output, dangerouslySetInnerHTML, innerHTML without sanitization |
| Auth bypass | Missing authorization checks, client-side-only access control |
| Secrets in code | API keys, tokens, passwords committed or logged |
| Unsafe deserialization | Parsing untrusted JSON/YAML without validation, eval of user input |
| CSRF / CORS | Missing CSRF tokens, overly permissive CORS configuration |
Maintainability
| Check | What to look for |
|---|---|
| Coupling | Components tightly bound to implementation details of other modules |
| Duplication | Same logic repeated in multiple places; candidate for extraction |
| Test coverage | Untested happy paths, missing edge-case tests, brittle test setup |
| Dead code | Unused exports, commented-out blocks, unreachable branches |
| Unclear abstractions | Over-abstraction (unnecessary indirection) or under-abstraction (god functions) |
| Upgrade path | Deprecated APIs, framework-version-specific hacks, pinned dependencies |
Step 3: Output as a Prioritized Finding List
Organize every finding by severity using the classification table below.
Severity Classification
| Severity | Qualifies when... | Examples |
|---|---|---|
| Critical | Causes data loss, security breach, or crash in production | SQL injection, unhandled null on critical path, race condition corrupting state |
| High | Breaks functionality or significantly degrades UX | Logic error in business rule, missing error handling on API call, auth check skipped |
| Medium | Impacts quality but doesn't break things | N+1 query on secondary page, moderate duplication, missing test for edge case |
| Low | Minor improvement opportunity | Slightly better naming, small refactor for clarity, non-critical performance tweak |
| Nit | Stylistic or trivial; optional to address | Extra whitespace, import order, comment wording, personal preference |
Finding Format
For each finding, include:
- Severity: Critical / High / Medium / Low / Nit
- Dimension: Which of the five dimensions it falls under
- Location: File path and line number (or range)
- Issue: What the problem is (one sentence)
- Suggestion: How to improve it (concrete, with code snippet when helpful)
- Why it matters: Impact on users, developers, or the system
Summary Section
After all findings, include:
- Total count by severity
- Top 3 priorities to address first
- Positive patterns observed (what the code does well)
- Overall assessment (one paragraph)
Tone Guidance
- Use "Consider X" not "You should X."
- Use "This could Y" not "This will Y" unless certain.
- Praise good patterns: "Nice use of early returns here" or "Good separation of concerns."
- Explain the "why" for every suggestion; reviewees learn more from reasoning than rules.
- Acknowledge trade-offs: "This adds complexity but improves testability."
- When uncertain, say so: "I'm not sure about the intent here — if Z is the goal, then consider W."
NEVER:
- Nitpick style when there are critical issues (prioritize ruthlessly)
- Flag something without a concrete suggestion for improvement
- Assume malice or carelessness — the author may have context you don't
- Rewrite entire functions in suggestions — keep diffs small and focused