awesome-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. Bundled file (load on demand): - [`references/smell-baseline.md`](references/smell-baseline.md) — the named design smells the Standards axis carries when the repository documents no conventions of its own, each with the direction of its fix, plus the two rules that bind them (the repo's own standard always wins; every smell is a heuristic, never a violation). Read it during Phase 4 and when running the Standards axis of a two-axis review. ## Work Process ### Phase 1: Understand Scope 1. Identify review scope —