# General Codereview > Perform thorough code reviews following Google's 5-step methodology. Use when reviewing pull requests, change lists, or any code changes to ensure quality, correctness, and maintainability. Use when this capability is needed. - Skill: `tomevault-io/general-codereview` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/general-codereview` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/general-codereview/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/general-codereview --- # General Code Review Skill A comprehensive code review methodology based on Google's engineering practices. Follow these 5 steps to perform effective and thorough code reviews. ## Step 1: Pre-screen Before diving into the code, perform a quick pre-screening: ### Check Size - **Reasonable size**: A change list of ~300 lines of code is typically reasonable - **Too large**: Larger CLs should be strongly discouraged unless necessary - Leave a comment asking if the CL can be broken down into smaller, logically complete parts - Ask for the reason if breaking down is not possible - **Small is OK**: Even single-line changes are fine as long as they are logically complete ### Verify You're the Right Reviewer Ask yourself: - Am I familiar enough with this code area? - Do I understand the language, environment, and context? - Is there someone better suited to review this? If you're not the ideal reviewer but no one else is available, prepare to quickly learn about the unfamiliar aspects. ## Step 2: Understand After pre-screening, focus on understanding the change from the author's perspective. ### Purpose Ask: **"Do I know the overall purpose of this CL?"** - The purpose should be clearly stated in the CL description - If unclear, request clarification - Even self-explanatory code needs a clear description for future maintainers - Remember: even the author may need to refer back to the description later ### Workflow Context Ask: **"Was I expecting this CL? Does it match my expectations?"** Consider: - Is this CL part of a larger project or design doc? - Does it align with the task distribution and design documentation? - Are there dependencies mentioned? - Other changes that need to happen before this CL can function - Other CLs that are blocked by this change ### Design Decisions Verify that important design decisions are: - Documented in the code description - Explained with rationale when non-obvious ## Step 3: Verify Now verify the implementation matches the stated intent. ### Code-Description Alignment - **Verify the code does what the description says** - Flag any discrepancies between stated purpose and actual implementation ### Test Coverage Verify relevant tests exist for: | Category | What to Check | |----------|---------------| | Design decisions | Tests that validate key architectural choices | | Important defaults | Tests for default values and their behavior | | Complex logic | Tests for intricate algorithms or business logic | | Edge cases | Zero, null, empty, boundary conditions, if-statement edges | ## Step 4: Optimize Look for opportunities to improve the code's efficiency and maintainability. ### Logic Optimization - Can the algorithm be simplified? - Are there unnecessary computations? - Is the control flow optimal? ### Library Usage - Is the best library being used for this task? - Are there more appropriate or efficient alternatives? - Is the library being used correctly and efficiently? ## Step 5: Check Style Final pass for code style and conventions. ### Style Checklist - [ ] Follows project/team coding standards - [ ] Consistent naming conventions - [ ] Proper formatting and indentation - [ ] Clear and helpful comments - [ ] No dead code or debugging artifacts --- ## Quick Reference Checklist ``` □ Pre-screen □ Size reasonable (~300 lines)? □ Am I the right reviewer? □ Understand □ Purpose clear in description? □ Expected in current workflow? □ Design decisions documented? □ Verify □ Code matches description? □ Tests cover design decisions? □ Tests cover defaults and edge cases? □ Optimize □ Logic optimizable? □ Library choices optimal? □ Check □ Style guidelines followed? ``` --- *Acknowledgment: This methodology is based on reflections from working at Google, with thanks to mentors and teammates who helped improve these code review skills.* --- > Converted and distributed by [TomeVault](https://tomevault.io/claim/xinbenlv) — claim your Tome and manage your conversions.