plugins/style-guides/skills/style-guide-frameworks/SKILL.md
# Style Guide Frameworks > Frameworks and reference patterns for building effective writing style guides. ## Knowledge Base ### Industry Style Guide Comparison | Style Guide | Best For | Key Stance | |------------|----------|------------| | Google Developer Style Guide | Developer documentation | Present tense, active voice, second person | | Microsoft Writing Style Guide | Product documentation | Conversational, task-oriented, accessible | | Apple Style Guide | Consumer-facing docs | Minima
npx skillsauth add hermeticormus/librecopy-claude-code plugins/style-guides/skills/style-guide-frameworksInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Frameworks and reference patterns for building effective writing style guides.
| Style Guide | Best For | Key Stance | |------------|----------|------------| | Google Developer Style Guide | Developer documentation | Present tense, active voice, second person | | Microsoft Writing Style Guide | Product documentation | Conversational, task-oriented, accessible | | Apple Style Guide | Consumer-facing docs | Minimal, precise, design-aware | | Stripe Documentation Style | API documentation | Direct, example-heavy, technically precise | | Chicago Manual of Style | Long-form content | Comprehensive grammar reference |
A complete style guide covers these areas:
Voice & Tone
├── Brand voice definition
├── Tone variations by context
└── Persona description
Language Rules
├── Grammar (tense, voice, person)
├── Capitalization
├── Punctuation
├── Numbers and dates
└── Abbreviations and acronyms
Formatting
├── Heading hierarchy
├── Lists (bulleted vs numbered)
├── Tables
├── Code blocks and inline code
├── Images and diagrams
└── Callouts and admonitions
Terminology
├── Preferred terms glossary
├── Terms to avoid
├── Product-specific vocabulary
└── Domain-specific definitions
Accessibility & Inclusion
├── Plain language guidelines
├── Inclusive language rules
├── Alt text standards
└── Reading level targets
Content Types
├── Per-type guidelines (tutorial, reference, etc.)
├── Template for each type
└── Examples for each type
Voice is constant. It is who you are. Like a person's personality. Tone varies by situation. Like how a person adapts to different conversations.
Example voice: "Clear, confident, helpful."
| Situation | Tone Adjustment | |-----------|----------------| | Error message | Empathetic, solution-oriented | | Tutorial | Patient, encouraging | | API reference | Precise, neutral | | Release announcement | Enthusiastic, grateful | | Security advisory | Urgent, serious |
Vale is the standard linter for prose. Configuration structure:
# .vale.ini
StylesPath = .vale/styles
MinAlertLevel = suggestion
[*.md]
BasedOnStyles = Vale, Google, Project
Custom rule types:
| Audience | Target Grade Level | Test | |----------|--------------------|------| | General public | Grade 6-8 | Flesch-Kincaid | | Business users | Grade 8-10 | Flesch-Kincaid | | Developers | Grade 10-12 | Coleman-Liau | | Academics | Grade 12+ | Gunning Fog |
tools
# User Doc Patterns > Patterns for writing clear, accessible end-user documentation. ## Knowledge Base ### User Documentation vs Developer Documentation | User Docs | Developer Docs | |-----------|---------------| | Task-oriented ("How do I...") | Concept-oriented ("How does it work...") | | Plain language | Technical language | | Screenshots and visual aids | Code examples | | Step-by-step procedures | API references | | Feature names and UI labels | Function signatures and parameters | | A
tools
# Tutorial Structures > Pedagogical patterns and frameworks for creating effective technical tutorials. ## Knowledge Base ### The Tutorial Spectrum Tutorials exist on a spectrum between two extremes: | Recipe | Concept Guide | |--------|--------------| | "Do exactly this" | "Understand this idea" | | Step-by-step | Explanation-heavy | | Fast to complete | Deep understanding | | Low retention | High retention | The best tutorials blend both: steps for doing, explanations for understanding.
tools
# Tutorial Patterns ## Tutorial vs. How-to Guide: The Critical Distinction Before writing, identify which document is actually needed: | Tutorial | How-to Guide | |----------|-------------| | "Build a REST API in Node.js" | "Add JWT authentication to your Express API" | | For someone new to this | For someone who knows the domain | | Explains why each step is done | Steps are efficient, minimal explanation | | Has checkpoints, explores | Numbered steps, no detours | | Learner reaches a comple
tools
# Tech Blogging Patterns ## The Developer Reading Pattern Developers do not read technical posts linearly. They scan in this order: 1. Headline (is this relevant to me?) 2. Code blocks (is this real code I can use?) 3. Headers (what does this cover?) 4. First paragraph (what's the point?) 5. Key takeaways / conclusion (is it worth reading fully?) Design for scanning first, reading second. Put real code within the first 25% of the post. ## The Before/After Pattern The contrast between a pain