Build or audit a comprehensive brand style guide that documents the full brand system including story, logo system, color, typography, imagery, voice, applications, and dos/don'ts. Use this skill whenever the user wants to create brand guidelines, document an existing brand, build a brand book, audit an existing style guide for completeness, or produce the artifact that other teams will reference for years. Triggers on style guide, brand guidelines, brand book, brand standards, brand manual, style sheet, brand documentation, brand reference. Also triggers when the brand identity is finished and needs to be documented for handoff to designers, developers, vendors, or future team members.
6k tokens
context cost
the whole folder, loaded on every use
3
files
instructions only
0
copies elsewhere
how many repositories repackaged it
512
stars on the repo
on the repository, not the skill itself
Install
one command, takes just this skill from the repository
Document the brand system so other people can use it without ambiguity. This is the artifact that lives longest. Designers, developers, agencies, and vendors will reference it for years. Build it like a reference manual, not a presentation.
This skill assumes the brand identity is designed (run brand-identity first if not). The output of this skill is the canonical reference document.
When to use
Creating brand guidelines for a finished identity
Documenting an existing brand that has no formal guide
Auditing an existing style guide for gaps or inconsistencies
Building a brand book to hand to vendors, partners, or new team members
Updating a guide after a major brand evolution
When NOT to use
The brand identity is not yet designed (use brand-identity)
Brand voice work specifically (use brand-voice for the voice doc, then integrate)
Building UI components (use design-standards or design-system)
How the brand sounds. (Pulled from brand-voice work if done separately.)
Voice attributes (3 to 5 adjectives with "we are X, not Y" framing)
Tone shifts by context (onboarding, error, marketing, support, legal)
Vocabulary preferences (words we use, words we avoid)
Grammar and style rules
Examples (good and bad copy side by side)
7. Applications
The brand applied to real contexts.
Web (homepage, product pages, blog template)
Email (template, signature, transactional)
Social (post templates, profile imagery, story formats)
Print (business cards, letterhead, print ads)
Packaging (if applicable)
Signage (if applicable)
Internal documents (slides, reports, proposals)
Each with examples showing what good looks like
8. Dos and don'ts
The boundaries, illustrated.
Logo dos and don'ts (visual examples of correct and incorrect use)
Color dos and don'ts (combinations to use, combinations to avoid)
Type dos and don'ts (treatments to use, treatments to avoid)
Composition dos and don'ts (layout patterns that work, ones that do not)
Voice dos and don'ts (phrases that fit, phrases that do not)
The dos and don'ts section is what people actually reference in practice. Make it the easiest section to scan.
Workflow
Inventory the inputs. What identity work is finished? What voice work is finished? What is missing?
Confirm the format. Is this a PDF, a web page, a Notion doc, a printed book, or all of the above? Different formats have different production requirements.
Section by section, draft. Use the template in references/style-guide-template.md.
Stress-test with real examples. For every rule, find a real application example. Rules without examples get ignored.
Get review from the people who will use it. Designers, developers, marketers. They will surface gaps.
Version control. Style guides evolve. Date the doc. Note what changed in each version.
Publish in the format the team will actually open. A 200-page PDF that lives on a shared drive is dead weight. A web page or Figma file with a clear URL gets used.
Failure patterns
Skipping the "what we are not" sections. Without rejection rules, anything becomes acceptable.
Document with no examples. Rules without visual examples are abstract and ignored.
Document with only examples. Examples without rules cannot be applied to new situations.
Static PDF that no one opens. Ship the guide in the format the team uses daily (web page, Figma, Notion, etc.).
No version history. When the brand evolves, no one knows which rules changed or when.
Aspirational rules. Rules the brand does not actually follow get treated as suggestions. Document what is actually true, not what is wished.
Treating "dos and don'ts" as filler. This section is what people use most. Invest in it.
Output format
Default output is a multi-section markdown document or a structured set of files, plus a presentation-ready version (web page, PDF, or Figma) for sharing with stakeholders.
For consumer-facing presentation, build a web page version that imports from these source files. The source files are canonical. The presentation is a view of them.