code-reviewlisted

# Code Review Structured review of changes so they are correct, secure, and maintainable before merge. **Why this matters:** Review is the last line of defense before code hits main. A good review catches bugs and security issues early and keeps the codebase readable for everyone—including the author in six months. The goal isn’t to nitpick; it’s to ship with confidence and leave the code better than you found it. ## When to Activate - Reviewing pull requests or merge requests before merge - Examining patches or diffs the user is about to submit - User asks for "code review", "review this PR", "check this change", or "review my diff" - After completing a feature (requesting review before proceeding) - Before refactoring (baseline check) or after fixing a complex bug ## Core Principle **Review the code, not the author.** Assume good intent. Be specific: cite file and line, state what is wrong and what to do instead. Prefer concrete edits or snippets over vague advice. ## Work Process ### Phase 1: Understand Scope 1. **Identify review scope** — Get base and head refs (e.g. `BASE_SHA`, `HEAD_SHA`) or the diff. Know what was implemented and what the requirements or plan were. 2. **Read the description** — PR/MR title and description, linked ticket or spec. Note intended behavior and any "don't review X" notes. 3. **Scan the diff** — Which files and areas changed (API, DB, UI, config). Note risk areas: auth, payments, data handling, new dependencies. If the diff output is