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.
Developer Documentation Style Guide
npx skills add wondelai/skills/technical-documentation --global This skill is compatible with Claude, Claude Code, Claude Cowork, Codex, Cursor, OpenClaw, Hermes Agent, and other agentskills.io-compatible agents.
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.
Key concepts from Developer Documentation Style Guide your agent applies
Reader and Document Type
Name the audience and the job first, then pick the type — tutorial, how-to, concept, reference, or README — and stop mixing them on one page.
You, Active, Present, Timeless
Address the reader directly, make the actor explicit, describe behavior in the present tense, and write so the page is still true in five years.
Procedures That Complete
Prerequisites before step one, one action per numbered step, and a verification step so the reader knows it worked.
Verified Code Samples
Every command, flag, and parameter checked against the code, with placeholders in a consistent form rather than plausible-looking invention.
Severity Order
Fix structure before voice and voice before word choice — reordering sections first makes the sentence-level edits land once instead of twice.
When to use Technical Documentation — and when not to
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.
Example prompts for the Technical Documentation skill
Audit our README against the style guide, score it, and give me the fixed version using technical-documentation skill
Docs auditWrite a getting-started guide from this repo without inventing any commands using technical-documentation skill
Getting startedRewrite the JSDoc in src/client.ts so it reads like proper API reference using technical-documentation skill
API referenceTurn the git log since v2.3 into a Keep a Changelog entry with a migration section using technical-documentation skill
Release notesTechnical Documentation vs the other Code Quality skills
All 6 Code Quality skills are free and install the same way — the only question is which framework fits the job in front of you.
| Skill | Based on | Best for |
|---|---|---|
| Clean Code | Clean Code — Robert C. Martin | Writing readable, maintainable code |
| Pragmatic Programmer | The Pragmatic Programmer — Andrew Hunt & David Thomas | Practical software craftsmanship |
| Refactoring | Refactoring — Martin Fowler | Improving code design through systematic refactoring |
| Software Design | A Philosophy of Software Design — John Ousterhout | Reducing complexity through thoughtful software design |
| Legacy Code | Working Effectively with Legacy Code — Michael C. Feathers | Safely change untested code: seams and characterization tests |
| Technical Documentation | Developer Documentation Style Guide — Google | Audit and write developer docs: reader fit, procedures, API reference |
Frequently asked questions
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.
Install Technical Documentation
Free, open-source, and ready in 30 seconds.
npx skills add wondelai/skills/technical-documentation --global MIT Licensed · Works with Claude, Claude Code, Claude Cowork, Codex, Cursor, OpenClaw, Hermes Agent & other agentskills.io agents · No account needed
Don’t guess your AI engineering level.
Measure it.
AI Developer Scorecard
How production-grade is your AI engineering?
Twenty-five questions across the practices that separate vibe-coding from production-grade engineering. Instant score, per-section breakdown, and a 30/60/90-day playbook.
Score 0–75 · 30/60/90-day playbook Score yourself For CTOs & foundersCTO Scorecard
Is your engineering team ready for AI at scale?
Twenty-five questions on how your org adopts AI — adoption, governance, automation, and ROI. See where you sit on the path from Reactive to Strategic Leader.
Score 0–75 · Reactive → Strategic Leader Score your orgWe build the skills you already use. Now we’ll build yours.
Fixed-price engagements, quoted after a 15-minute call. Shipped to production, or you don't pay the final milestone.