Use when writing or reviewing technical documentation to follow Google's documentation style guide — enforce active voice and present tense, apply sentence case to headings, fix list and procedure formatting, mark code/UI elements correctly, flag non-inclusive terminology, and remove time-specific phrasing. Triggers on tasks involving technical writing, doc review, style consistency, inclusive language, or formatting standards.
64
75%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Fix and improve this skill with Tessl
tessl review fix ./skills/google-style-guide/SKILL.mdAttribution: This skill adapts material from the Google developer documentation style guide, © Google, licensed under CC BY 4.0. The content here has been condensed and restructured into skill form. As a derivative work it is distributed under the same CC BY 4.0 license — not MIT.
Apply Google's documentation style guide principles to technical writing:
Use active voice and present tense. Example: "The API returns..." not "The API will return..."
Use sentence case for headings. Make them descriptive and actionable.
code font for code elements, filenames, and UI elementsYOUR_PROJECT_IDSeveral rules usually apply at once. Before/after for a typical doc sentence:
Before: "Once the Configuration File has been Edited by the user, the changes will be applied by the system and the build process will then be triggered."
After: "After you edit the
configfile, the system applies your changes and triggers the build."
What changed: passive → active voice; future → present tense; title case → sentence case; wordy clauses tightened; filename in code font.
When reviewing a doc, make one focused pass per concern rather than reading once and hoping to catch everything:
For detailed documentation, see:
6b52554
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.