agentsclimarketplace

Google eng practices

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

Minimalist Cross-Agent Skills Manager

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.

What its author says it does

Copied from the file, not written here

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.

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)

Gives 0 of the 12 instructions most code review skills give in ~1.2k tokens

Counted across 610 of the 674 authors here whose files we hold, read 2026-08-06

  • push back with technical reasoning if wrongin 60 of 610, across 24 files
  • ask for clarification on unclear itemsin 51 of 610, across 16 files
  • fix critical issues immediatelyin 45 of 610, across 29 files
  • implement one item at a timein 45 of 610, across 11 files
  • group findings by severityin 44 of 610, across 43 files
  • verify feedback against the codebasein 42 of 610, across 8 files
  • dispatch a code reviewer subagentin 39 of 610, across 23 files
  • fix important issues before proceedingin 37 of 610, across 22 files
  • test each fix individuallyin 35 of 610, across 7 files
  • reply in github comment threadsin 33 of 610, across 5 files
  • check for security vulnerabilitiesin 31 of 610, across 27 files
  • factualize corrections without over-explainingin 30 of 610, across 2 files

Said here and by no other author read

  • Defer to technical facts over personal preferences
  • Comment on code, never the developer
  • Resolve conflicts using synchronous conversation
  • Schedule follow-up reviews for emergencies

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. 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.