Technical Documentation
Audit and write developer docs: reader fit, procedures, API reference
Audit, write, and improve developer documentation the way Google’s technical writers do. This skill gives your AI agent the Developer Documentation Style Guide and the Technical Writing courses as a working method — start from the reader’s task, verify every command against the code, then fix structure before voice and voice before word choice.
npx skills add wondelai/skills/technical-documentation --global developers.google.com
Developer Documentation Style Guide Google View the book
02 What it is
What is the Technical Documentation skill?
Technical Documentation packages Google’s Developer Documentation Style Guide into a skill your agent loads while it writes or reviews docs. It names the reader and the document type first, verifies every command and parameter against the code, then applies the guide in severity order — so a README stops being a feature list and becomes something a stranger can follow.
03 Key concepts
Five principles your agent applies.
Drawn from Developer Documentation Style Guide — not advice it repeats back to you, but decisions it makes while it works.
04 Fit
When to use it, and
when not to.
four symptoms it fixes, and four it doesn't.
Reach for it when
Your README grew by accretion and new users still open issues asking how to install.
You need a getting-started guide or how-to written from the code, with no invented flags or endpoints.
Docstrings and JSDoc are technically present but nobody can use them as API reference.
A release needs a changelog and a migration section that readers can actually act on.
Reach for something else when
You are writing landing-page or marketing copy. StoryBrand Messaging aims at persuasion, not instruction.
The problem is naming and comments inside the code itself. that is Clean Code’s territory.
You want the docs site’s information architecture and navigation designed. UX Heuristics covers findability.
The docs are fine and the question is who reads them and why — that is a product-discovery job.
05 Prompts
Say it like this.
Name the skill at the end of a prompt and the agent applies the framework rather than a vibe. Or say nothing — it loads on its own when a task matches.
Audit our README against the style guide, score it, and give me the fixed version using technical-documentation skill
Write a getting-started guide from this repo without inventing any commands using technical-documentation skill
Rewrite the JSDoc in src/client.ts so it reads like proper API reference using technical-documentation skill
Turn the git log since v2.3 into a Keep a Changelog entry with a migration section using technical-documentation skill
06 About the author
07 Same stack
The stack it sits in.
Six Code Quality skills. Most people run two: this one, and whichever fits the next problem.
All Code Quality skills08 Questions
Before you install.
How do I install the Technical Documentation skill?
Run npx skills add wondelai/skills/technical-documentation --global. It takes about 30 seconds and needs no account. The Technical Documentation skill then works in Claude, Claude Code, Claude Cowork, Codex, Cursor, OpenClaw and Hermes Agent — anything that reads the open agentskills.io format — and your agent loads it on its own when a task calls for it. It is free and MIT-licensed, and the source is at https://github.com/wondelai/skills.
Which book is the Technical Documentation skill based on?
It packages Developer Documentation Style Guide by Google — house style behind developers.google.com, Android, and Google Cloud. The skill distils the book's method into instructions your agent follows while it works, covering reader and document type, you, active, present, timeless and procedures that complete. It sits in the Code Quality part of the library.
Does this only apply to English documentation?
No. The skill separates two layers. Structural and content rules — document type, headings, procedures, code samples, second person, active voice, timeless writing, accessibility — apply in any language. Rules tagged [EN] cover English spelling, the serial comma, contractions and the word list, and they auto-pass for a doc in another language. The audit score adjusts accordingly, and the skill never translates a document unless you ask.
How does it avoid inventing commands and flags that do not exist?
By treating unverifiable facts as a blocking finding rather than a style nit. Every command, flag, parameter and endpoint has to be checked against the code or the CLI’s own help output before it lands in the doc, and anything that cannot be verified is flagged instead of guessed. A doc can score well on structure and voice and still be marked not shippable while a single unverified fact remains in it.
What does the score actually measure?
It runs a ten-row diagnostic and reports how many rows pass, so you get a number plus the list of what failed and the exact edits that close each gap. Nine or ten ships as is; seven or eight needs word- and voice-level edits; five or six means restructuring sections before re-editing; four or below means rewriting from the doc-type skeleton. The blocking gate on wrong facts and uncompletable procedures sits outside the score.
Will it rewrite our docs into generic Google-voice?
The guide is explicit that these are guidelines rather than rules, and that established domain terminology wins over house style. Your project’s own style guide takes precedence over Google’s, so the skill applies your conventions first and Google’s only where you have none. What it does enforce is internal consistency — one term for one concept across the set — which is usually the thing that was missing, not personality.
One skill, one command.
Install Technical Documentation, or the whole stack.
npx skills add wondelai/skills/technical-documentation --global MIT licensed · Claude, Claude Code, Codex, Cursor, OpenClaw, Hermes · No account