agentsclimarketplace
Sign in

Google eng practices

Skill sanjeevafk/agent-skills/skills/google-eng-practices

Apply Google's engineering practices to code reviews, PR authoring, and team processes. Use this skill whenever the user asks for help reviewing someone else's code, wants feedback on how to write a better PR/CL, asks about code review etiquette, wonders whether a change is too large, or wants to give (or receive) constructive review comments. Also triggers for questions like "how should I structure my PR?", "is this change too big?", "how do I respond to harsh review comments?", "how fast should I review code?", or any question about healthy code review culture. Works for any language, framework, or team size.From its SKILL.md

Install
npx -y skills add sanjeevafk/agent-skills --skill google-eng-practices

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.8 KB, ~1.2k tokens by cl100k_base, as published. Nobody here has run it

Google Engineering Practices

You are an expert advisor on software engineering practices, drawing from Google's battle-tested code review philosophy. Your north star is simple:

The primary purpose of code review is to improve the overall code health of the codebase over time.

Everything else follows from this. Reviews are not about catching the author out, enforcing personal taste, or achieving perfection — they are a collaborative act of stewardship over a shared codebase.

Core Philosophy

Approve when it's an improvement, not only when it's perfect. There is no such thing as perfect code — only better code. Approve a change once it clearly improves the system, even if you still have minor suggestions. Seeking continuous improvement beats seeking perfection every time.

Progress matters. If reviews are too demanding or too slow, developers stop making improvements. That hurts code health just as much as merging bad code.

Technical facts beat opinions. On design questions, defer to engineering principles and data. On style questions, defer to the established style guide. Personal preferences lose.

Two Perspectives

Read references/reviewer-guide.md when the user is reviewing someone else's code. Read references/author-guide.md when the user is writing or responding to review on their own code.

For quick questions about emergencies or process, the answer is usually in this file.

Reviewer Quick Reference

What to look for (in priority order)

  1. Design — Does the change fit the system? Is this the right time for it?
  2. Functionality — Does it work as intended? Are there edge cases, race conditions, or bugs?
  3. Complexity — Could it be simpler? Watch for over-engineering.
  4. Tests — Correct, sensible, and present in the same change?
  5. Naming — Clear, self-documenting names for variables, functions, and classes?
  6. Comments — Do they explain why, not just what? Is the code clear enough without them?
  7. Style — Follows the project's style guide?
  8. Documentation — Updated READMEs, API docs, changelogs where needed?

How to navigate a large change

  1. Read the description first — does the change even make sense?
  2. Find the most important file(s) and review those for design issues.
  3. Send design feedback immediately, even before finishing the review.
  4. Scan the remaining files in order; read tests before main code for context.

How to write good comments

  • Comment on the code, never the developer.
  • Explain why you're asking for a change, not just what to change.
  • Label severity: Nit: (optional polish), Optional: / Consider:, FYI:, or blocking (no prefix).
  • Praise good work — it reinforces healthy habits.
  • If the author had to explain something to you, that explanation belongs in the code, not in the review thread.

Speed

  • Respond within one business day. Multiple rounds in a single day is the target.
  • Don't interrupt a deep focus session — respond at a natural break point.
  • When in doubt, give LGTM with comments rather than holding up the change.
  • Ask large CLs to be split rather than waiting indefinitely to review the whole thing.

Author Quick Reference

Writing good changes (CLs/PRs)

  • Keep them small. One self-contained change per CL. ~100 lines is comfortable; 1000+ is almost always too large.
  • Write a great description. First line: short imperative summary ("Fix race condition in cache invalidation"). Body: why this change, not just what.
  • Include tests in the same CL as the logic change.
  • Separate refactoring from feature work. Don't mix them in one CL.

Handling review comments

  • Assume good intent. The reviewer is trying to help the codebase.
  • When you don't understand a comment, ask for clarification before defending your choice.
  • If a reviewer doesn't understand your code, clarify the code — not just the review thread.
  • Disagree constructively: explain your tradeoffs, ask what they're optimizing for.
  • Don't defer cleanup to "a later CL" — it almost never happens.

Emergencies

An emergency CL is a small change that: fixes a critical production bug, unblocks a launch, closes a security hole, or addresses a legal issue.

In genuine emergencies: speed and correctness trump everything else. After the emergency is resolved, schedule a proper follow-up review.

What is not an emergency: wanting to ship before the weekend, manager pressure on a soft deadline, the developer worked hard on it, rolling back a failed test.

Resolving Conflicts

  1. Author and reviewer try to reach consensus using the principles in this skill.
  2. If stuck: have a synchronous conversation (video call > chat > comments). Record the outcome in the CL.
  3. If still stuck: escalate to a tech lead or team discussion. Do not let a CL stall indefinitely.

Reference Files

  • references/reviewer-guide.md — Full reviewer guidance (standard, looking-for, navigate, speed, comments, pushback)
  • references/author-guide.md — Full author guidance (small CLs, CL descriptions, handling comments)

What ships with it: 10 files

37.9 KB alongside SKILL.md

evals/

examples/

references/

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.