# Technical Documentation > Audit and write developer docs: reader fit, procedures, API reference — an AI agent skill based on *Developer Documentation Style Guide* by Google. Published 2026-08-30 · Updated 2026-08-30 · Code Quality · Free and MIT-licensed Canonical: https://skills.wondel.ai/skills/technical-documentation/ Source: https://github.com/wondelai/skills/tree/main/technical-documentation **Install:** `npx skills add wondelai/skills/technical-documentation --global` ## 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. ## About Google House style behind developers.google.com, Android, and Google Cloud. Google’s Developer Documentation Style Guide is the public house style its technical writers maintain for developers.google.com, Android, and Google Cloud, released under CC BY 4.0. The companion Technical Writing One and Two courses are the internal engineer training Google opened to everyone. ## Example prompts - Audit our README against the style guide, score it, and give me the fixed version using technical-documentation skill _(Docs audit)_ - Write a getting-started guide from this repo without inventing any commands using technical-documentation skill _(Getting started)_ - Rewrite the JSDoc in src/client.ts so it reads like proper API reference using technical-documentation skill _(API reference)_ - Turn the git log since v2.3 into a Keep a Changelog entry with a migration section using technical-documentation skill _(Release notes)_ ## 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. ## Related - All Code Quality skills: https://skills.wondel.ai/skills/code/ - Clean Code: https://skills.wondel.ai/skills/clean-code/ - Pragmatic Programmer: https://skills.wondel.ai/skills/pragmatic-programmer/ - Refactoring: https://skills.wondel.ai/skills/refactoring-patterns/ - Software Design: https://skills.wondel.ai/skills/software-design-philosophy/ - Legacy Code: https://skills.wondel.ai/skills/working-with-legacy-code/