google-code-review-author

Guides authors in preparing, splitting, and describing code changes for review using Google's engineering practices.

Updated Aug 22, 2026
One-click install
npx skills add https://github.com/chughtapan/google-guide-skills --skill google-code-review-author-chughtapan
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: google-code-review-author
Source: https://github.com/chughtapan/google-guide-skills/tree/main/skills/google-code-review-author
Command: npx skills add https://github.com/chughtapan/google-guide-skills --skill google-code-review-author-chughtapan

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Authors often submit oversized, poorly described changes that slow reviews, frustrate reviewers, and create confusion in version control history. This Skill applies Google's engineering practices so change authors produce small, well-described, reviewable changelists. ## Core Features & Use Cases - Small CL Guidance: Explains why and how to keep changelists small, including strategies for splitting work by files, horizontally, vertically, or by stacking dependent changes. - CL Description Writing: Provides rules for writing informative first lines and bodies that serve reviewers and future code searchers. - Review Interaction: Covers handling reviewer comments constructively, resolving conflicts, and recognizing genuine emergencies versus soft deadlines. - Use Case: Before opening a pull request that touches 40 files, use this Skill to split the work into self-contained changes with tests, write a clear description, and respond to reviewer feedback without conflict. ## Quick Start Use the google-code-review-author skill to help me split my large feature change into small reviewable CLs and write a proper description for each one.

Frequently Asked Questions about google-code-review-author

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I split a large code change into smaller CLs?

Split large changes by stacking dependent CLs, grouping files needing different reviewers, separating refactorings from feature changes, or splitting horizontally by layer or vertically by feature. Each CL should be one self-contained change that keeps the build working.

What makes a good CL description for code review?

A good CL description starts with a short imperative first line summarizing what the change does, followed by a blank line and an informative body explaining why. Include context like bug numbers, design links, and tradeoffs so future readers understand the change.

How should I respond to reviewer comments on my code?

Respond to reviewer comments by first clarifying the code itself or adding code comments rather than only replying in the review tool. Stay courteous, ask for clarification when needed, and discuss tradeoffs collaboratively instead of defensively.

When is a large CL acceptable in code review?

Large CLs are acceptable for whole-file deletions or trusted automated refactorings where the reviewer mainly verifies intent. Otherwise, get reviewer consent in advance, expect a long review, and be extra diligent about tests and bugs.

What counts as an emergency code review?

An emergency CL is a small change fixing a production outage, major security hole, legal issue, or blocked launch with a hard deadline. Wanting to launch sooner, reviewer timezones, or Friday deadlines do not qualify as emergencies.