code-reviewlisted

# Code Review Structured review of code changes with severity labels. > Part of the task planning workflow. See [references/workflow-overview.md](references/workflow-overview.md) for the full pipeline. ## Severity Levels - **[blocking]**: Must fix before merge. Bugs, security issues, data loss risks. - **[important]**: Should fix before merge. Missing error handling, poor patterns, test gaps. - **[nit]**: Minor style or clarity issue. Fix if convenient. - **[suggestion]**: Optional improvement idea. Take it or leave it. - **[praise]**: Something done well. Call it out. ## Process ### Step 1: Read project conventions Read project docs (CLAUDE.md, contributing guides, style guides) to understand conventions before reviewing. ### Step 2: Read the diff ```bash git diff main...HEAD ``` Or for a PR: `gh pr diff $NUMBER` ### Step 3: Identify intent Determine what the change is trying to accomplish. Read linked task docs, PR description, or commit messages. ### Step 4: Identify touched files List all files added, modified, or deleted. Group by area (backend, frontend, tests, config). ### Step 5: Run automated checks Run whatever automated tooling the project has: - Typecheck - Linter - Tests (at minimum the affected ones) Report results. If automated checks fail, note as `[blocking]`. ### Step 6: Manual review Review each file change against these dimensions: - **Correctness**: Does the code do what it's supposed to? Edge cases handled? - **Simplicity**: Is this