google-dev-docs — Claude Code skill: Google-style developer docs
A skill that makes the agent write technical docs the Google way: action headings, second person, present tense, active voice. Useful for READMEs, tutorials and API references.
npx skills add surendranb/writing-skills --skill google-dev-docs -a claude-codeWhat google-dev-docs does
The skill is a SKILL.md with writing rules the agent picks up when you ask for developer-facing content: READMEs, tutorials, reference guides, error messages. It needs a standard Markdown parser and agent context. That is the whole setup.
Eight rules sit inside. Headings open with an action verb or gerund. Every snippet carries its imports, setup and expected output. Words like “this” and “it” must point at a clear noun, and terms stay identical across guides. Errors get a short explanation plus the fix.
A document follows one path: the reader's goal in the title, prerequisites, numbered steps with code, then a verification step. references/REFERENCE.md holds the mechanical details on numbers, percentages, ranges and units; the skill loads it only when a draft contains such items. The rewrite examples are plain: a bloated sentence with “in order to” becomes “To initialize the SDK, call setup()”.
What it helps with
- rewrite a README to follow the Google developer style
- build a tutorial with numbered steps and a final check
- move API reference text into present tense and active voice
- turn a vague error message into one that names the fix
- strip “Simply run” and “Just configure” from a draft
Example prompts for the agent
- Write a README for
client.pyin Google style: action headings, “you”, present tense - Edit
docs/setup.md: drop future tense and give every snippet its imports and expected output - Rewrite the messages in
errors.mdto say what broke and how to fix it
How to install google-dev-docs
1Skills CLI (Vercel)
npx skills add surendranb/writing-skills --skill google-dev-docs -a claude-code2Manually: put the files in place
~/.claude/skills/google-dev-docs/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/google-dev-docs/
1Skills CLI (Vercel)
npx skills add surendranb/writing-skills --skill google-dev-docs -a codex2Manually: put the files in place
.agents/skills/google-dev-docs/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add surendranb/writing-skills --skill google-dev-docs -a cursor2Manually: put the files in place
.cursor/skills/google-dev-docs/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install surendranb/writing-skills google-dev-docs2Manually: put the files in place
.github/skills/google-dev-docs/SKILL.md1Skills CLI (Vercel)
npx skills add surendranb/writing-skills --skill google-dev-docs -a gemini-cli2Platform CLI
gemini skills install https://github.com/surendranb/writing-skills --path skills/google-dev-docsManually: put the files in place
.devin/skills/google-dev-docs/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add surendranb/writing-skills --skill google-dev-docs -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about google-dev-docs
How do I install google-dev-docs in Claude Code?
Run npx skills add surendranb/writing-skills --skill google-dev-docs -a claude-code. The skill file lands at ~/.claude/skills/google-dev-docs/SKILL.md.
What does google-dev-docs do?
It gives the agent Google developer documentation style rules: task-based headings, second person, present tense, active voice, and code samples with full context.
Do I need to read references/REFERENCE.md in advance?
No. The skill pulls it in on demand when a draft includes numbers, percentages, ordinals, ranges, abbreviations or units.
Source text
SKILL.md · MIT
---
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
1. **Second person.** Address the developer directly as "you"; avoid "we", "us", or third-person generalities.
2. **Present tense.** Describe current system behavior in present tense ("Returns a 200 OK status", not "Will return").
3. **Task-oriented headings.** Start headings with gerunds or action verbs ("Configuring authentication", not "Authentication overview").
4. **Active voice.** "The server processes the request" rather than "The request is processed by the server".
5. **Code blocks with context.** Every code snippet must include necessary imports, setup, and expected output.
6. **Pronoun clarity.** Ensure "this", "that", and "it" clearly point to a preceding noun.
7. **Consistent terminology.** Use identical terms across guides, API references, and UI labels.
8. **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."
© surendranb · MIT · surendranb/writing-skills