writing

name

writing

description

How to write every piece of prose in this repository: documentation, Storybook docs and MDX, component and token descriptions in registry manifests, READMEs, skill files, code comments, story sample data, and any other developer- or user-facing text. Use whenever creating or editing text, writing or revising docs, naming or describing a component or token, choosing example or sample data, or wording a comment. Always apply so the voice stays consistent: Google developer documentation style, timeless, with no AI tells, no em dashes, and no implementation details that go stale or leak source-app internals.

Writing in this repository

Follow the Google developer documentation style guide. The highlights are the baseline for tone, grammar, and formatting. This file adds the rules specific to this repository; where the two disagree, this file wins.

Vendored files (anything tracked in skills-lock.json) are exempt; never edit them.

The Google baseline

The rules from the guide that this repository leans on hardest:

• Use second person and active voice. Make clear who performs the action.
• Use present tense and sentence case headings.
• Use standard American spelling and serial commas.
• Put conditions before instructions. Use descriptive link text.
• Use numbered lists for sequences and bulleted lists for everything else. Put code in code font and UI elements in bold.
• Write timeless documentation. Never anchor text to a point in time: no "currently", "now", "soon", "new", "existing", "not yet", "planned". Document the present state of the product, not its history or roadmap.
• Don't document future features or pre-announce. If something does not exist, write nothing about it; if a process applies whenever it runs, write it as an instruction.