| name | quality-review |
| description | Code quality review checklist. Correctness, coding philosophy compliance, test coverage, documentation quality. Findings ranked by severity in plain English. |
Quality Review
Review code quality for changed files. Explain all findings in plain English as if speaking to someone with no programming background.
Review Checklist
For each changed file, evaluate:
- Correctness -- Does the code do what the task says? Logic errors, off-by-one mistakes, missing edge cases?
- Coding philosophy -- Immutability patterns (no
let, no mutations, functional transformations)? Correct function structure (variables, side effects, return)?
- Test coverage -- Tests present? Testing behavior, not implementation details? Edge cases covered?
- Documentation -- JSDoc on new functions explaining "why"? Preambles on new files?
- Code clarity -- Readable variable names? Unnecessary complexity? Could a new team member understand this?
Output Format
Rank findings by severity:
Critical (must fix before merge)
Broken logic or violates hard project rules.
Warning (should fix)
Could cause problems later or reduce maintainability.
Suggestion (nice to have)
Minor improvements, not blocking.
Finding Format
For each finding:
- What -- Plain English description, no jargon
- Why -- What could go wrong? Concrete examples
- Where -- File path and line number
- Fix -- Specific, actionable suggestion
Example
What: The function changes the original list instead of creating a new one.
Why: Other code using that list could see unexpected changes, causing hard-to-track bugs.
Where: src/utils/transform.ts:42
Fix: Use [...items].sort() instead of items.sort() to create a copy first.
Rules
- Run
bun run test to confirm tests pass
- Run the task's proof command to confirm the implementation works
- Never approve code with failing tests
- If no issues found, say so clearly -- do not invent problems
