Audit, write, and improve developer documentation the way Google's technical writers do: start from the reader's task, verify every fact against the code, then apply the style guide in severity order — structure before voice, voice before word choice.

Write for the reader's task, not the product's feature list. Google's guide asks for prose that is conversational but not frivolous, precise, and consistent, because a developer reading docs is trying to get something done, not to admire the product. Two framing rules from the guide shape everything below:

Rules come in two layers. Structural and content rules (headings, procedures, code samples, second person, active voice, timeless docs, accessibility) apply to documentation in any language. Rules tagged (spelling, serial comma, contractions, the word list) apply only to English text — skip them for other languages, and never translate a document unless asked.

Goal: 10/10. Score = number of Quick Diagnostic rows passed (10 rows, 1 point each; the row auto-passes for non-English docs). Bands: 9-10 = ships as is; 7-8 = word- and voice-level edits only; 5-6 = restructure sections, then re-edit; ≤4 = rewrite from the doc-type skeleton. Blocking findings — wrong or unverifiable facts, a procedure that can't be completed, information that exists only in an image or in an image without alt text — are a separate gate: the doc is not shippable at any score until they're fixed. Report the score, the failed rows, and the exact edits that reach 10/10.

Core concept: Every page serves one reader with one task. Name both before writing a word — audience and level, what they'll be able to do afterwards — and pick the document type that fits: tutorial (learn by doing), how-to (accomplish a task), concept (understand), reference (look up), README (orient and start).

Why it works: Readers scan for their task; a page that mixes concept, procedure, and reference forces them to read everything to find anything.

See references/document-types.md when choosing or restructuring a doc type — skeletons for README, getting started, tutorial, how-to, and concept pages, the audience and scope statements, and the self-editing pass for large doc sets.

Core concept: Address the reader as "you", make the actor of every sentence explicit, describe behavior in the present tense, and write as if the page will be read in five years.

See references/voice-and-words.md when a doc's tone is off or inconsistent — the voice rules with the guide's exact exceptions, inclusive and global-audience language, and the full word list.

Core concept: Put the condition before the instruction, keep one idea per sentence, and choose the plain word the guide's word list prefers.

See references/voice-and-words.md when auditing word choice — the word list table (avoid → use → why), abbreviation rules, and modal verbs.

Core concept: Structure is the reader's map. Headings in sentence case read as a table of contents; lists carry parallel items introduced by a full sentence; tables have header rows; notices are rare and mean something.

See references/structure-and-formatting.md when fixing page structure — heading, list, table, notice, cross-reference, link-text, image, number, and date rules with before/after pairs.

Core concept: A procedure is a numbered list of single imperative actions, each stating where to act and what to expect. Code is set in code font, introduced by a sentence ending in a colon, and uses placeholders the reader can't mistake for literals.

See references/procedures-and-code.md when writing steps or samples — the full procedure rules, UI-element and device verbs, code-in-text, placeholder, command-line syntax, and the sample-code quality checklist.

Core concept: Reference text is descriptive, complete, and formulaic on purpose — readers look things up, so every entry must exist and read the same way.

See references/api-reference.md when writing or auditing reference material — the verb-by-category table, parameter, return, and exception patterns, one complete JSDoc example, and CLI help conventions.

Core concept: A changelog is documentation for the reader who is about to upgrade. Each entry states what changed, what it means for them, and what to do — in the structure of Keep a Changelog, in the voice of the rest of the docs.

See references/release-notes.md when writing release notes or a migration guide — the Keep a Changelog skeleton, entry patterns per category, deprecation wording, and the migration-guide procedure.

Core concept: Three modes, one discipline: intake → local conventions → read as the reader → verify facts → apply rules by severity → output in a fixed shape.

ALWAYS output audits in this format:

undefined

Score: X/10 — [band] Shippable: yes | no (blocking findings below) Diagnostic: N/10 — failed rows: [row numbers + one-line reason each] Doc type / reader: [type] for [audience, level] Language: [en | xx — [EN] rules skipped] Local style guide: [file found and honored | none — Google applies] Blocking: [wrong/unverifiable facts, unfollowable steps, image-only information — or "none"] Findings: | # | Location | Rule (ID + name) | Before | After | Severity | Rewrite plan: [ordered: structure → voice → words; what to do first to reach 10/10]

See [references/audit-checklist.md](references/audit-checklist.md) when running any audit or rewrite — the full rule table with IDs and severities, the severity rubric, non-English handling, a Vale configuration, and a worked mini-audit.

Google's Developer Documentation Style Guide is the public house style that Google's technical writers maintain for developers.google.com, Android, and Google Cloud documentation; the companion Technical Writing One and Two courses are Google's internal engineer training, released publicly. This skill adapts both under CC BY 4.0 (per Google's site policies) and adds Keep a Changelog for release notes; it is an independent adaptation, not endorsed by Google.