Consistency Standards
Establish uniform patterns for naming, terminology, and content reuse.
When to Use / Not Use
Use when:
- Establishing naming conventions for a new project
- Auditing existing code or docs for consistency issues
- Creating a terminology glossary to standardize vocabulary
- Defining voice and tone guidelines for different content types
- Designing content reuse strategies (DRY documentation)
- Onboarding new team members with style standards
Do NOT use when:
- Formal ontology or semantic modeling -> use
ontology-design
- Content type and CMS schema design -> use
content-modelling
- Writing the actual documentation content -> use
documentation-generator
Decision Tree
What are you standardizing?
├── How things are NAMED (variables, files, endpoints, columns)
│ ├── Single language? -> Case style guide (§Naming Conventions)
│ └── Multi-language stack? -> Per-context rules + mapping between layers (§Naming Conventions)
├── How things are CALLED (terminology, synonyms, product names)
│ └── Multiple terms for same concept? -> Glossary with preferred + forbidden terms (§Terminology)
├── How things SOUND (voice, tone, formality)
│ └── Different contexts need different voices? -> Per-context voice rules (§Voice and Tone)
├── How content is REUSED (repeated sections across docs)
│ └── Same content in 3+ places? -> Snippets/variables/conditionals (§Content Reuse)
└── Not sure / combination? -> Start with audit (§Style Checklist)
Naming Conventions
Case Styles
| Style |
Example |
Use For |
| camelCase |
getUserName |
JS variables, methods |
| PascalCase |
UserProfile |
Classes, components |
| snake_case |
user_name |
Python, databases |
| kebab-case |
user-profile |
URLs, CSS classes |
| SCREAMING_SNAKE |
MAX_RETRIES |
Constants |
File Naming
[type]-[name]-[variant].[ext]
component-button-primary.tsx
doc-api-reference.md
Cross-Layer Mapping Rules
When a stack has multiple languages, define how names map between layers:
| Layer |
Convention |
Example |
| Database column |
snake_case |
user_name |
| API response field |
camelCase |
userName |
| Frontend variable |
camelCase |
userName |
| URL path segment |
kebab-case |
/user-profile |
| File name |
kebab-case |
user-profile.tsx |
Terminology Standards
Glossary Template
| Term | Definition | Do Not Use |
|------|------------|------------|
| click | Select with mouse | press, hit |
| select | Choose from options | pick, click on |
| enter | Type in field | input, write |
Voice and Tone
| Context |
Voice |
Example |
| Instructions |
Direct, active |
"Click Save" |
| Errors |
Helpful, calm |
"Let's fix this" |
| Success |
Positive, brief |
"Done!" |
Content Reuse Patterns
Single-Source Components
| Pattern |
Use Case |
| Snippet |
Reusable text block |
| Variable |
Product name, version |
| Conditional |
Audience-specific content |
| Template |
Structured format |
DRY Documentation
<!-- Include shared content -->
{{> shared/authentication.md}}
<!-- Use variables -->
Install {{product_name}} v{{version}}
Style Checklist
Anti-Patterns
| Anti-Pattern |
Problem |
Solution |
| Synonym sprawl |
Multiple terms for same concept ("user"/"account"/"member") |
Create glossary with one preferred term + explicit "Do Not Use" list |
| Inconsistent capitalization |
Feature names capitalized randomly |
Define rule: capitalize only proper nouns and product names |
| Mixed voice |
"you should"/"the user must"/"we recommend" in same doc |
Per-context voice guide: instructions=direct active, errors=helpful, success=brief |
| Orphaned content |
Outdated references to renamed features |
Audit checklist: search for forbidden terms, add to CI lint step |
| Standards without enforcement |
Glossary exists but nobody follows it |
Add lint rules (ESLint, Ruff) + PR review checklist + automated docs linting |
| Over-standardizing |
Rule for every possible variation |
Focus only on inconsistencies causing real confusion or maintenance cost |
| Page-based reuse |
Same content copy-pasted into 8 documents |
Single-source snippet with {{> shared/section.md}} includes |
1---2name: consistency-standards3description: Establish and enforce uniform naming conventions, taxonomy standards, style guides, and content reuse patterns across a project. Use when the user asks to audit for consistency, standardize naming, create a style guide, align terminology across docs, eliminate drift, or define reuse patterns across content or code. NOT for formal knowledge graphs or semantic ontologies (use ontology-design). NOT for CMS content types or editorial workflows (use content-modelling). NOT for language-specific code conventions (use typescript-development or python-development).4---56# Consistency Standards78Establish uniform patterns for naming, terminology, and content reuse.910## When to Use / Not Use1112**Use when:**13- Establishing naming conventions for a new project14- Auditing existing code or docs for consistency issues15- Creating a terminology glossary to standardize vocabulary16- Defining voice and tone guidelines for different content types17- Designing content reuse strategies (DRY documentation)18- Onboarding new team members with style standards1920**Do NOT use when:**21- Formal ontology or semantic modeling -> use `ontology-design`22- Content type and CMS schema design -> use `content-modelling`23- Writing the actual documentation content -> use `documentation-generator`2425## Decision Tree2627```28What are you standardizing?29├── How things are NAMED (variables, files, endpoints, columns)30│ ├── Single language? -> Case style guide (§Naming Conventions)31│ └── Multi-language stack? -> Per-context rules + mapping between layers (§Naming Conventions)32├── How things are CALLED (terminology, synonyms, product names)33│ └── Multiple terms for same concept? -> Glossary with preferred + forbidden terms (§Terminology)34├── How things SOUND (voice, tone, formality)35│ └── Different contexts need different voices? -> Per-context voice rules (§Voice and Tone)36├── How content is REUSED (repeated sections across docs)37│ └── Same content in 3+ places? -> Snippets/variables/conditionals (§Content Reuse)38└── Not sure / combination? -> Start with audit (§Style Checklist)39```4041## Naming Conventions4243### Case Styles4445| Style | Example | Use For |46|-------|---------|---------|47| camelCase | getUserName | JS variables, methods |48| PascalCase | UserProfile | Classes, components |49| snake_case | user_name | Python, databases |50| kebab-case | user-profile | URLs, CSS classes |51| SCREAMING_SNAKE | MAX_RETRIES | Constants |5253### File Naming5455```56[type]-[name]-[variant].[ext]57component-button-primary.tsx58doc-api-reference.md59```6061### Cross-Layer Mapping Rules6263When a stack has multiple languages, define how names map between layers:6465| Layer | Convention | Example |66|-------|-----------|---------|67| Database column | snake_case | `user_name` |68| API response field | camelCase | `userName` |69| Frontend variable | camelCase | `userName` |70| URL path segment | kebab-case | `/user-profile` |71| File name | kebab-case | `user-profile.tsx` |7273## Terminology Standards7475### Glossary Template7677```markdown78| Term | Definition | Do Not Use |79|------|------------|------------|80| click | Select with mouse | press, hit |81| select | Choose from options | pick, click on |82| enter | Type in field | input, write |83```8485### Voice and Tone8687| Context | Voice | Example |88|---------|-------|---------|89| Instructions | Direct, active | "Click Save" |90| Errors | Helpful, calm | "Let's fix this" |91| Success | Positive, brief | "Done!" |9293## Content Reuse Patterns9495### Single-Source Components9697| Pattern | Use Case |98|---------|----------|99| Snippet | Reusable text block |100| Variable | Product name, version |101| Conditional | Audience-specific content |102| Template | Structured format |103104### DRY Documentation105106```markdown107<!-- Include shared content -->108{{> shared/authentication.md}}109110<!-- Use variables -->111Install {{product_name}} v{{version}}112```113114## Style Checklist115116- [ ] Consistent capitalization117- [ ] Uniform date/time formats118- [ ] Standardized UI element names119- [ ] Single voice throughout120- [ ] Glossary terms used correctly121- [ ] Code style matches project122123## Anti-Patterns124125| Anti-Pattern | Problem | Solution |126|---|---|---|127| Synonym sprawl | Multiple terms for same concept ("user"/"account"/"member") | Create glossary with one preferred term + explicit "Do Not Use" list |128| Inconsistent capitalization | Feature names capitalized randomly | Define rule: capitalize only proper nouns and product names |129| Mixed voice | "you should"/"the user must"/"we recommend" in same doc | Per-context voice guide: instructions=direct active, errors=helpful, success=brief |130| Orphaned content | Outdated references to renamed features | Audit checklist: search for forbidden terms, add to CI lint step |131| Standards without enforcement | Glossary exists but nobody follows it | Add lint rules (ESLint, Ruff) + PR review checklist + automated docs linting |132| Over-standardizing | Rule for every possible variation | Focus only on inconsistencies causing real confusion or maintenance cost |133| Page-based reuse | Same content copy-pasted into 8 documents | Single-source snippet with `{{> shared/section.md}}` includes |
viktorbezdek