Individual skill
technical-documentation
Audit, write, and improve developer documentation using Google's Developer Documentation Style Guide and Technical Writing courses. Use this skill for any documentation work, even when the user names no style guide: "audit our docs", "review this README", "write a README", "getting started guide", "how-to or tutorial", "API reference", "docstrings", "CLI help text", "changelog or release notes", "migration guide", or "our docs are confusing". Also use it when writing docs from code, rewriting a doc for clarity, fixing headings, procedures, or code samples, or enforcing consistent voice and terminology across a docs set — prefer it over editing documentation unaided. Covers reader and doc-type fit, second person and active voice, procedures, headings, lists and tables, code samples and placeholders, link text, notices, the word list, timeless docs, and accessibility. For code comments and naming, see clean-code. For marketing or landing-page copy, see storybrand-messaging.
plugins/wondelai-skills/skills/technical-documentation/SKILL.md
Source commit d8d5d75f83da9f16d8aad5bab5f5b341a4770a30
What was checked
- Matches the observed repository HEAD
- Yes
- Scanner rules are current
- No
- Repository scan complete
- No
- Skill scan complete
- No
- Observed behavior
- Not checked yet
- Last checked
- Nov 7, 2026
These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.
Install this skill
Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.
An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.
Repository context
- Repository stars (not skill ratings)
- 2,640
- Repository last updated
- Nov 2, 2026
- License
- MIT
Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.
- agent-skills Repository topic
- ai-skills Repository topic
- claude-code Repository topic
- claude-code-marketplace Repository topic
- claude-code-plugin Repository topic
- claude-code-skills Repository topic
- claude-plugins Repository topic
- claude-skills Repository topic
- skill-md Repository topic
- skillsmp Repository topic
- docs Derived category
- writing Derived category
- engineering Derived category
- marketing Derived category
- security Derived category
- productivity Derived category
- education Derived category
- docs-api Derived category
- productivity-notes Derived category
Files and excerpt
File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.
Browse files
SKILL.mdcore · 21,757 bytesSKILL.mdcore · 21,757 bytesreferences/api-reference.mddoc · 19,451 bytesreferences/audit-checklist.mddoc · 19,521 bytesreferences/document-types.mddoc · 11,804 bytesreferences/procedures-and-code.mddoc · 14,321 bytesreferences/release-notes.mddoc · 18,196 bytesreferences/structure-and-formatting.mddoc · 14,151 bytesreferences/voice-and-words.mddoc · 16,628 bytes
Read excerpt
# Technical Documentation
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.
## Core Principle
**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:
- **Guidelines, not rules.** Depart from the guide when doing so improves the content — established domain terminology wins — but stay consistent within the document.
- **Precedence.** A project's own style guide comes first, then Google's guide, then Merriam-Webster (spelling), the Chicago Manual of Style (general style), and the Microsoft Writing Style Guide (technical style).
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 `[EN]` (spelling, serial comma, contractions, the word list) apply only to English text — skip them for other languages, and never translate a document unless asked.
## Scoring