| name | google-dev-docs |
| description | Use when writing API documentation, READMEs, tutorials, reference guides, error messages, or any technical content for developers using the Google developer documentation style guide. |
| compatibility | Requires standard Markdown parser and agent context |
Google Developer Documentation Style
Write precise, task-oriented technical documentation with second-person address and active voice.
The core rule
Task-oriented headings, present tense, second person ("you"), active voice.
Workflow: state user goal in title → prerequisites first → numbered steps with concrete code examples → verification step.
Mechanics
- Second person. Address the developer directly as "you"; avoid "we", "us", or third-person generalities.
- Present tense. Describe current system behavior in present tense ("Returns a 200 OK status", not "Will return").
- Task-oriented headings. Start headings with gerunds or action verbs ("Configuring authentication", not "Authentication overview").
- Active voice. "The server processes the request" rather than "The request is processed by the server".
- Code blocks with context. Every code snippet must include necessary imports, setup, and expected output.
- Pronoun clarity. Ensure "this", "that", and "it" clearly point to a preceding noun.
- Consistent terminology. Use identical terms across guides, API references, and UI labels.
- Concise error messages. Explain what went wrong and how to fix it immediately.
Verify
- Headings use gerunds or action verbs describing tasks
- Sentences consistently use second person ("you")
- Code snippets are complete, syntactically valid, and tested
- Active voice used throughout instructions
- Present tense used for API descriptions
Do not
- Use future tense for deterministic software behavior ("The method will return...")
- Leave code snippets without imports or setup context
- Use vague filler phrases ("Simply run...", "Just configure...")
- Mix second person and first person within the same tutorial
References
For exact mechanical rules (numbers, percentages, ordinals, ranges, abbreviations, units), read references/REFERENCE.md when a draft contains any of these — load on demand, not upfront.
Example transformations
Before: "In order to initialize our SDK, users are required to first invoke the setup method, after which time you will be able to make API requests successfully."
After: "To initialize the SDK, call setup(). Once initialized, you can make API requests."
Before: "Simply add the configuration dictionary to your project and you're good to go!"
After: "Add the configuration dictionary to your project configuration file."
