Write Technical Docs
Produce accurate, task-oriented, scannable, accessible documentation. Project facts, user intent, and local style outrank general editorial guidance.
Establish Authority
- Follow explicit user instructions and project terminology, templates, lint rules, and neighboring docs.
- Apply this skill and Google guidance where local rules are silent.
- Preserve intentional consistency unless it misleads readers.
- Ask only when competing interpretations materially change meaning, audience, or structure.
For non-English content, apply information design and accessibility without imposing US English grammar or punctuation. Never invent commands, flags, API behavior, prerequisites, output, compatibility, names, or links.
Load Only Needed References
- Voice, clarity, grammar, inclusion, localization, accessibility: voice-and-language.md.
- Organization, headings, procedures, lists, tables, notices, images: structure-and-formatting.md.
- Code, commands, placeholders, UI labels, and links: code-ui-and-links.md.
- Capitalization, abbreviations, numbers, dates, filenames, examples, trademarks: wording-and-naming.md.
- Exact or current Google source lookup: source-index.md.
For a full draft or review, read the first four. Use the source index only when exact current guidance matters.
Write or Rewrite
- Identify reader, goal, document type, assumptions, prerequisites, and evidence.
- Inspect neighboring documentation and project rules.
- Put outcome and essential context first; organize around reader tasks and decisions.
- Use the smallest useful structure and descriptive sentence-case headings.
- Write directly and respectfully, usually with “you,” active voice, present tense, and conditions before instructions.
- Make procedures executable: one primary action per step, nearby commands/results, explicit optional actions.
- Format technical tokens, UI labels, links, media, lists, and tables with the applicable references.
- Verify technical claims and test samples when authorized.
- Remove repetition, filler, unsupported claims, cultural shorthand, and “easy” language.
- Preserve target format and make the smallest complete edit.
Review
Check in this order: technical fidelity, task completeness, information architecture, language, presentation, then accessibility. A polished sentence does not validate a technical claim. When asked only to review, report actionable findings with locations; do not edit.
Prefer accuracy and comprehension over mechanical compliance. Preserve required identifiers exactly, define necessary terms, and use justified exceptions consistently.
Complete
Verify that the opening states the outcome; prerequisites precede actions; headings and links work out of context; procedures are ordered; terminology and formatting are consistent; code/UI/output are distinct and accurate; images have useful alt text; dates and units are unambiguous; and no claim promises unsupported behavior.
Report blocking correctness separately from editorial improvements. For writes, summarize changed documents, verified evidence, and unresolved technical assumptions.
1---2name: write-technical-docs3description: Write, rewrite, or review developer documentation using project terminology and the Google Developer Documentation Style Guide. Use for tutorials, how-to and concept pages, API/CLI docs, READMEs, troubleshooting, UI instructions, release notes, or editorial reviews in any language.4---56# Write Technical Docs78Produce accurate, task-oriented, scannable, accessible documentation. Project facts, user intent, and local style outrank general editorial guidance.910## Establish Authority11121. Follow explicit user instructions and project terminology, templates, lint rules, and neighboring docs.132. Apply this skill and Google guidance where local rules are silent.143. Preserve intentional consistency unless it misleads readers.154. Ask only when competing interpretations materially change meaning, audience, or structure.1617For non-English content, apply information design and accessibility without imposing US English grammar or punctuation. Never invent commands, flags, API behavior, prerequisites, output, compatibility, names, or links.1819## Load Only Needed References2021- Voice, clarity, grammar, inclusion, localization, accessibility: [voice-and-language.md](references/voice-and-language.md).22- Organization, headings, procedures, lists, tables, notices, images: [structure-and-formatting.md](references/structure-and-formatting.md).23- Code, commands, placeholders, UI labels, and links: [code-ui-and-links.md](references/code-ui-and-links.md).24- Capitalization, abbreviations, numbers, dates, filenames, examples, trademarks: [wording-and-naming.md](references/wording-and-naming.md).25- Exact or current Google source lookup: [source-index.md](references/source-index.md).2627For a full draft or review, read the first four. Use the source index only when exact current guidance matters.2829## Write or Rewrite30311. Identify reader, goal, document type, assumptions, prerequisites, and evidence.322. Inspect neighboring documentation and project rules.333. Put outcome and essential context first; organize around reader tasks and decisions.344. Use the smallest useful structure and descriptive sentence-case headings.355. Write directly and respectfully, usually with “you,” active voice, present tense, and conditions before instructions.366. Make procedures executable: one primary action per step, nearby commands/results, explicit optional actions.377. Format technical tokens, UI labels, links, media, lists, and tables with the applicable references.388. Verify technical claims and test samples when authorized.399. Remove repetition, filler, unsupported claims, cultural shorthand, and “easy” language.4010. Preserve target format and make the smallest complete edit.4142## Review4344Check in this order: technical fidelity, task completeness, information architecture, language, presentation, then accessibility. A polished sentence does not validate a technical claim. When asked only to review, report actionable findings with locations; do not edit.4546Prefer accuracy and comprehension over mechanical compliance. Preserve required identifiers exactly, define necessary terms, and use justified exceptions consistently.4748## Complete4950Verify that the opening states the outcome; prerequisites precede actions; headings and links work out of context; procedures are ordered; terminology and formatting are consistent; code/UI/output are distinct and accurate; images have useful alt text; dates and units are unambiguous; and no claim promises unsupported behavior.5152Report blocking correctness separately from editorial improvements. For writes, summarize changed documents, verified evidence, and unresolved technical assumptions.
Hu-Wentao