# Write Technical Docs

> 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.

- Skill: `hu-wentao/write-technical-docs` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds@latest add hu-wentao/write-technical-docs`
- Raw SKILL.md: https://api.skillmd.com/api/skills/hu-wentao/write-technical-docs/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: Hu-Wentao (https://skillmd.com/u/hu-wentao)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/hu-wentao/write-technical-docs

---


# Write Technical Docs

Produce accurate, task-oriented, scannable, accessible documentation. Project facts, user intent, and local style outrank general editorial guidance.

## Establish Authority

1. Follow explicit user instructions and project terminology, templates, lint rules, and neighboring docs.
2. Apply this skill and Google guidance where local rules are silent.
3. Preserve intentional consistency unless it misleads readers.
4. 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](references/voice-and-language.md).
- Organization, headings, procedures, lists, tables, notices, images: [structure-and-formatting.md](references/structure-and-formatting.md).
- Code, commands, placeholders, UI labels, and links: [code-ui-and-links.md](references/code-ui-and-links.md).
- Capitalization, abbreviations, numbers, dates, filenames, examples, trademarks: [wording-and-naming.md](references/wording-and-naming.md).
- Exact or current Google source lookup: [source-index.md](references/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

1. Identify reader, goal, document type, assumptions, prerequisites, and evidence.
2. Inspect neighboring documentation and project rules.
3. Put outcome and essential context first; organize around reader tasks and decisions.
4. Use the smallest useful structure and descriptive sentence-case headings.
5. Write directly and respectfully, usually with “you,” active voice, present tense, and conditions before instructions.
6. Make procedures executable: one primary action per step, nearby commands/results, explicit optional actions.
7. Format technical tokens, UI labels, links, media, lists, and tables with the applicable references.
8. Verify technical claims and test samples when authorized.
9. Remove repetition, filler, unsupported claims, cultural shorthand, and “easy” language.
10. 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.