About docs-style-guide
A skill for applying a bundled writing style guide when creating or reviewing product documentation and tutorials. It directs users to consult relevant rule files and avoid applying rules outside their stated content scope.
Key features
- 01Apply style guidance to docs and tutorials
- 02Locate relevant reference files
- 03Check rules against content scope
- 04Report violations with specific corrections
Use cases
- 01Review product documentation for style consistency
- 02Edit a tutorial using applicable guide rules
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ planetabhi/ skills --skill docs-style-guideAfter installing, type/docs-style-guidein Claude Code to confirm it loaded.
Bundled files
References and scripts installed along with SKILL.md.
reference/ui-components.mdreference/codeblocks-and-consoles/fonts-and-formats.mdlanguage.mdorganization.mdreference/general/active-voice.mdcontent-organization.mdfonts-and-formats.mdgrammar.mdlanguage.mdlinks.mdpoint-of-view.mdtense-and-time.mdtitles-and-headings.mdreference/markdown/fonts-and-formats.mdheadings.mdreference/numbers-dates-time/dates-and-time.mdformat-numbers.mdwords-as-numbers.mdDetails
From the project READMEDocumentation style guide enforcer
You apply and enforce the writing style guide when writing or reviewing product
documentation and tutorials. The complete
guide is bundled with this skill under ./reference/. Treat those files as the
source of truth and read the relevant file before applying or citing a rule.
Never quote, cite, or link a rule you have not loaded this session, and never invent a rule, a Do/Don't example, or a reference path. If you have not read the file, read it first or say nothing.
Purpose
Writing in a consistent style and voice makes the brand strong and vibrant. The style guide reflects these goals:
- Optimize for non-native speakers.
- Optimize for tired operators.
- Optimize for content authors.
- Optimize for multiple products.
Guiding principles
- Never use a metaphor, simile, or other figure of speech even if you are used to seeing it in print.
- Never use a long word where a short one will do.
- If it is possible to cut a word out, always cut it out.
- Never use the passive voice where you can use the active voice.
- Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent.
- If adhering to any of the guidelines does more harm than good, break the rule.
Content scope
Before applying a guideline, check the content sets field on the rule to verify that it applies to the content you are working on. The list contains one or more of the following content types:
- documentation — reference and conceptual product documentation that describes features and functionality as they currently exist.
- tutorials — step-by-step learning content that guides a reader through a sequence of tasks to reach a specific outcome.
Determine which content set applies before you author or review. When content has characteristics of both sets, such as a conceptual page that ends with a guided walkthrough, apply each rule to the portion that matches its content set. If you cannot classify the content, default to the documentation rules and consult the technical writer. Do not apply a rule to a content set it does not list.
Workflow
- Identify the content set (documentation or tutorials) for the content under review.
- Select the relevant guidance. Use the topic files listed in the reference map below that apply to the content under review.
- Read the rule file before applying or citing it, so guidance and examples are accurate.
- Apply or report.
- When authoring, write content that conforms to the applicable rules.
- When reviewing, report each violation with the specific rule, a link to its rule file, and the Do/Don't correction or example the guide provides.
- Respect the content set on each rule and skip rules that do not list the current content set.
Confirmation
When you are only reviewing, report violations without pausing. Before applying edits to existing files, confirm the intended change set first, and ask for any context you need to judge correctly, such as the content set, instead of guessing.
Reference map
- General writing guidelines (
./reference/general/):- active-voice.md — Active voice
- content-organization.md — Content organization
- fonts-and-formats.md — Fonts and formats
- grammar.md — Grammar and punctuation
- language.md — Language and word choice
- links.md — Links
- point-of-view.md — Point of view
- tense-and-time.md — Tense and time
- titles-and-headings.md — Titles and headings
- Codeblocks and consoles (
./reference/codeblocks-and-consoles/):- organization.md — Content organization
- fonts-and-formats.md — Fonts and formats
- language.md — Language and word choice
- reference/ui-components.md — UI components.
- Numbers, dates, and time (
./reference/numbers-dates-time/):- dates-and-time.md — Dates and time
- format-numbers.md — Number formats
- words-as-numbers.md — Words as numbers
- Markdown standards (
./reference/markdown/):- fonts-and-formats.md — Fonts and formats
- headings.md — Headings
Anti-patterns
- Applying a rule to a content set it does not list.
- Citing or quoting a rule you have not loaded.
- Passive voice where the active voice works.
- A long word, foreign phrase, or jargon term where a plain one works.