Skip to content

v1.8.0 — technical-documentation (Google developer docs style guide)

Latest

Choose a tag to compare

@mjaskolski mjaskolski released this 29 Aug 23:39
· 1 commit to main since this release

One new skill brings the library to 65 skills / 51 frameworks / 14 metaskills, and opens a new source category: a public style guide rather than a book.

technical-documentation

Audit, write, and improve developer documentation the way Google's technical writers do — READMEs, getting-started guides, tutorials and how-tos, API reference and docstrings, CLI help text, changelogs, and migration guides.

Three modes share one discipline: intake → local conventions → read cold as the reader → verify facts → apply rules by severity → fixed output. An audit returns a scored report (Score: X/10, Shippable: yes/no, findings with rule IDs, before/after, and a rewrite plan). An improve pass returns the rewritten document plus a change log. A write pass refuses to invent — every command, flag, and parameter is traced to code or to you.

Built on Google's Developer Documentation Style Guide and the Technical Writing One and Two courses, with Keep a Changelog for release notes.

What makes it usable rather than a rule dump:

  • Sixty rules with stable IDs (R reader · V voice · W words · S structure · P procedures and code · A API reference · N release notes), each with a severity and an owner file. Findings cite the ID, so a review is arguable instead of a matter of taste.
  • Facts outrank style. Wrong or unverifiable content is Blocking — a separate gate from the score. Unverifiable facts become TODO(verify) markers; they are never guessed away, and never deleted.
  • Two rule layers. Structural rules (headings, procedures, code samples, second person, active voice, accessibility) apply to documentation in any language; [EN]-tagged rules (spelling, serial comma, contractions, the word list) are skipped for non-English docs, and nothing is translated unless you ask.
  • Your conventions win. The skill looks for CONTRIBUTING.md, STYLE.md, docs/style-guide.md, or .vale.ini first — a project's own guide outranks Google's, exactly as Google's guide instructs.
  • Sourced or labelled. Every rule cites its Google page slug; anything that isn't on one is marked (inferred) or (convention).

Seven reference files carry the detail: doc-type skeletons, voice and the word list, structure and formatting, procedures and code samples, API reference and CLI help, release notes and migration guides, and the full rule table with a worked mini-audit.

Also in this release

  • A non-book source variant. Skills adapted from a public style guide or standard now use ## About the Source in place of ## About the Author, with the source's license and an attribution line. Google's guide and courses are adapted here under CC BY 4.0; this is an independent adaptation, not endorsed by Google.
  • A Testing policy in CLAUDE.md — tautological tests considered harmful: tests that restate the implementation, re-derive the expected value with the code's own expression, or snapshot output nobody read prove nothing and are deleted on sight rather than fixed.
  • Validated against a no-skill baseline. Three tasks — audit a violation-seeded README, write a how-to from source files only, rewrite weak JSDoc — run with and without the skill and graded on behavior (violations found, facts preserved, no invented commands, code untouched). With the skill: every assertion passed; without it: 42%.

Install

/plugin marketplace add wondelai/skills
/plugin install code-craftsmanship@wondelai-skills

# or individually
npx skills add wondelai/skills/technical-documentation --global