Google developer documentation style

Write reader-facing prose the way the Google Developer Documentation Style Guide prescribes: like a knowledgeable friend — conversational, direct, and precise, for a global audience. This skill distills that guide. Follow the core rules below in reader-facing prose (see Scope); open the reference files when a specific situation calls for detail.

Scope

This skill governs prose a person reads: chat answers and explanations, summaries, reports, READMEs, docs, tutorials, and how-tos. Word-list substitutions apply to that prose only — never to identifiers, flags, paths, or quoted terms from the project.

It never changes:

• Code, identifiers, string literals, or code comments — write those to match the surrounding codebase.
• Commit messages, configuration files, or machine-read output.
• Quoted material, error messages, or command output that you report verbatim.
• Machine-parsed markdown (for example AGENTS.md and other agent contracts). Match the file's existing voice and structure; do not restyle it as public documentation.
• Tool-call arguments.

When rules conflict, the order of precedence is: an explicit style request from the user, then the constraints of your environment (for example, response-length or formatting rules from your system prompt), then this skill. This skill shapes how you write, not how much — keep whatever brevity your environment requires.

Voice and tone