google-dev-docs-style

Write and revise technical documentation following the Google developer documentation style guide.

Updated May 28, 2023
One-click install
npx skills add https://github.com/steveulrich/ProjectB --skill google-dev-docs-style-steveulrich
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: google-dev-docs-style
Source: https://github.com/steveulrich/ProjectB/tree/main/.cursor/skills/google-dev-docs-style
Command: npx skills add https://github.com/steveulrich/ProjectB --skill google-dev-docs-style-steveulrich

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Technical documentation often suffers from inconsistent voice, unclear procedures, ambiguous links, and accessibility issues. This Skill applies the Google developer documentation style guide so READMEs, API docs, tutorials, and reference pages stay clear, consistent, and readable for a global audience. ## Core Features & Use Cases - Style rule application: Enforces second person, active voice, sentence-case headings, Oxford commas, and unambiguous dates across any developer document. - Structured reference library: Loads on-demand guidance for voice and tone, formatting, lists and procedures, links, accessibility, and a common word list. - Pre-publish checklist: Runs a full editorial checklist covering voice, structure, procedures, and links before content ships. - Use Case: You draft a README for a new CLI tool. The Skill revises it to use task-based headings, numbered procedures with location-before-action steps, descriptive link text, and flags banned terms like "simply" and "click here". ## Quick Start Use the google-dev-docs-style skill to revise this README draft so it follows the Google developer documentation style guide.

Frequently Asked Questions about google-dev-docs-style

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

FAQPage Schema
How do I write documentation in Google developer style?▼

Identify the document type first, then apply voice and tone rules, sentence-case headings, and structured procedures. Finish by running the pre-publish checklist covering voice, formatting, procedures, and links before publishing.

What are the main rules of the Google developer documentation style guide?▼

Core rules include second person and active voice, sentence-case headings, numbered lists for sequences, descriptive link text, ISO or unambiguous date formats, and avoiding words like "please", "simply", and "click here".

How should I format procedures and numbered steps in technical docs?▼

Put location and goal before the action, use one action per step, and format single-step tasks as a bulleted item. Prefix optional steps with "Optional:" and use lowercase letters for sub-steps.

Does Google style allow passive voice in documentation?▼

Active voice is preferred so the actor is clear, but passive voice is acceptable when emphasizing the object, de-emphasizing the actor, or when the actor is irrelevant, such as "The file is saved."

What words should I avoid in developer documentation?▼

Avoid "please", "simply", "easy", "let's", "click here", "etc.", and directional terms like "above" or "below". Use "preceding" or "following" for document position and descriptive text for links.

When should I not follow the Google style guide strictly?▼

Project-specific style overrides take priority, and any rule can be broken when doing so improves clarity for the audience. Consistency within the document matters more than rigid rule compliance.