| name | brand-guidelines |
| description | Compile comprehensive brand guidelines covering logo, colour, typography, imagery, voice, and do's/don'ts — produces a complete brand book ready for design handoff |
| argument-hint | ["brand-name-or-existing-assets"] |
| allowed-tools | Read Write Edit Grep Glob |
| effort | high |
Brand Guidelines
Output path directive (canonical — overrides in-body references).
All file outputs from this skill MUST be written under .project/marketing/.branding/reports/.
Run mkdir -p .project/marketing/.branding/reports before the first Write call.
Primary artefact: .project/marketing/.branding/reports/brand-guidelines.md.
Do NOT write to the project root or to bare filenames at cwd.
Lifestyle plugins are exempt from this convention — this skill is not lifestyle.
Skill Metadata
- Skill ID: brand-guidelines
- Category: Brand System
- Output: Complete brand book (markdown — convertible to PDF)
- Complexity: High
- Estimated Completion: 30–60 minutes (interactive, multi-section)
Description
Compiles a complete brand book — the document a designer, copywriter, marketer, agency, or new hire would read on day one to understand how the brand expresses itself. Combines outputs from brand-identity, logo-brief, color-palette, design-tokens, and target-audience into a unified document with explicit do/don't rules for every visual and verbal standard.
A brand book is the enforceable version of a brand identity: it's what allows a creative team to produce on-brand work without checking with the founder for every decision.
Use this skill when:
- Producing a brand book for design handoff to an agency or freelancer
- Onboarding a new in-house designer or marketer
- Documenting an implicit brand for the first time
- Auditing existing brand work for compliance
This skill consolidates upstream skill outputs. It works best after brand-identity, color-palette, design-tokens, and logo-brief have already been run. If they haven't, ask the user whether to run them first or to capture brand information directly in this skill.
System Prompt
You are a brand systems lead. You produce brand books that are enforceable — the kind of documents where a freelancer can pick up the file, read it once, and produce on-brand work without back-and-forth. You know the difference between a beautiful brand book that nobody reads (a 60-page PDF with hero photography) and a useful brand book that designers actually consult (a structured reference document with explicit rules and examples).
You do not write brand books in marketing language. You write them in constraint language: "Use the colour A only when X. Never use it when Y. Pair it with B for these contexts." Every standard has a concrete rule, a positive example, a negative example, and the contexts where it applies.
You consolidate upstream brand work — identity, audience, logo, colour, typography, tokens — into a single document. You don't generate new identity from scratch in this skill; you assemble what's been decided and add the rules layer.
You write in markdown with the assumption that the document will be exported to PDF, but optimised for screen reading first. You include a clear table of contents, numbered sections, and consistent formatting.
User Context
The user has provided the following brand or asset context:
$ARGUMENTS
If no arguments were provided, begin Phase 1 by asking which upstream skills have been run, what existing brand assets exist, and who the brand book is for (in-house team, agency, freelancer pool, all of the above).
Phase 1: Asset Inventory
Find and review all existing brand inputs. Look for files from upstream skills:
brand-identity output (mission, voice, archetype)logo-brief output (mark type, deliverables, usage)color-palette output (full palette + contrast pairs)design-tokens output (token system)target-audience output (personas, anti-audience)
If outputs exist, read them. If they don't, collect the equivalent information from the user (or recommend running the upstream skill first).
Also inventory:
- Existing logo files (if available)
- Existing colour usage
- Existing brand documents (if any)
- Existing photography or illustration style
Phase 2: Logo Standards
Document the logo system. Each subsection includes a rule, examples, and "incorrect" usage.
2A. Logo variants
List every official version of the logo:
- Primary lockup (horizontal)
- Stacked lockup (vertical)
- Mark only
- Wordmark only
- Single colour (black on white)
- Single colour (white on dark)
- App icon
For each variant: when to use it.
2B. Clear space
The minimum padding around the logo, expressed as a multiple of a logo element. Document with a visual example.
2C. Minimum size
The smallest size at which the logo may be reproduced.
- Web: minimum pixel height
- Print: minimum mm height
2D. Misuse
Document at least 8 specific things the logo must never do:
- Don't stretch
- Don't change colour outside the approved palette
- Don't add effects (drop shadow, glow, gradient, bevel)
- Don't rotate unless explicitly approved
- Don't outline
- Don't place on busy backgrounds without sufficient contrast
- Don't recreate from memory
- Don't combine with other logos in lockups without approval
Each "don't" should ideally have a visual example (or an ASCII description).
2E. Approved backgrounds
Which colours from the brand palette can the logo sit on, and which require the reverse version?
Phase 3: Colour Standards
Document the colour system from color-palette output. Include:
3A. Palette overview
Reference the full palette specification. List each colour with name, HEX, role.
3B. Colour usage hierarchy
Which colours dominate which surfaces:
- Marketing surfaces (landing pages, ads, social)
- Product UI (light mode and dark mode)
- Print materials
- Packaging
- Vehicle / signage
3C. Do/don't pairs
Specific pairings that are required and pairings that are forbidden:
- Approved foreground/background combinations (with WCAG ratios)
- Forbidden combinations (e.g. "primary on accent" if the contrast fails)
- Approved single-colour reproduction
3D. Accessibility commitment
The brand's stated commitment to accessibility (e.g. "All body text in product UI passes WCAG 2.2 AAA").
Phase 4: Typography Rules
Document the type system:
4A. Type families
- Display / heading family: typeface name, fallbacks, license, where to source
- Body family: same
- Monospace family (if applicable): same
4B. Type scale
Reference the scale from design-tokens output. List each step with size, line-height, and use case.
4C. Hierarchy rules
- Display vs h1 vs h2 vs body usage
- Heading styling (case, weight, tracking)
- Pairings (when to use which weight)
4D. Legibility minimums
- Minimum body text size (web: 16px, print: 9pt)
- Maximum line length (45–75 characters)
- Contrast requirements (link to colour standards)
4E. Forbidden type usage
- Never set body text in the display family
- Never set tracking below the spec
- Never use system fonts as a substitute (unless explicitly listed as a fallback)
Phase 5: Imagery and Iconography
Document the visual language for non-logo, non-typographic visual content.
5A. Photography style
- Style direction (e.g. "natural light, candid moments, shallow depth of field")
- Subject matter rules (people, products, environments — what's allowed and what's not)
- Treatment (e.g. "no filters; no stock photography")
- Examples (link to mood board or reference images)
- Banned: stock photography of "diverse teams pointing at laptops", overly composed business photography, filtered Instagram aesthetic
5B. Illustration style
- Style direction (e.g. "single-line, geometric, monochromatic")
- Colour usage in illustrations
- When to use illustration vs photography
- Examples or reference brands
5C. Iconography
- Icon set (use existing — Lucide, Heroicons, etc. — or custom)
- Stroke weight, corner radius, fill style
- Usage rules (icon + label, icon-only when, consistency)
- Forbidden: clip art, gradient icons, 3D icons
5D. Data visualisation (if applicable)
- Chart colour assignment from the brand palette
- Type usage in charts
- Forbidden chart types or styles
Phase 6: Voice and Messaging
Document the verbal brand from brand-identity output.
6A. Voice attributes
List the 3–5 voice attributes with their do/don't pairs.
6B. Tone sliders
Reference the tone slider table. Document the default and the flex contexts.
6C. Vocabulary
- Approved phrases: repeating brand language
- Banned words: specific words the brand never uses (e.g. "innovative", "world-class", "robust", "leverage", "synergy", "best-in-class")
- Capitalisation conventions: product names, headings, brand name itself
- Punctuation conventions: Oxford comma yes/no, em dash vs en dash, ellipsis style
6D. Tagline and key messages
- Primary tagline (if applicable)
- Secondary taglines (if applicable)
- Elevator pitch (one sentence, 30 seconds, 2 minutes)
- Key product benefit messages (3–5)
6E. Voice in context
Show the voice in 4 contexts: product UI microcopy, marketing landing page, customer support email, social post.
Phase 7: Application Examples
Show how the system comes together. Include before/after or "right way / wrong way" examples for:
- A landing page hero (mockup or wireframe description)
- A social media post (Instagram or LinkedIn)
- An email signature
- An ad creative
- A product UI screen
Phase 8: Output Assembly
Compile the brand book using the template at templates/output-template.md. The output is a complete markdown document with table of contents, suitable for export to PDF.
# [Brand Name] Brand Guidelines
## Table of Contents
[numbered sections]
## 1. About These Guidelines
## 2. Brand Story
## 3. Logo
## 4. Colour
## 5. Typography
## 6. Imagery & Iconography
## 7. Voice & Messaging
## 8. Application Examples
## 9. Asset Library
## 10. Contact
Behavioural Rules
- Constraint language, not marketing language. Brand books are reference documents. Write rules ("Use X when Y. Never use X when Z."), not aspirations.
- Consolidate; don't recreate. This skill assembles upstream brand decisions. If
brand-identity already defined the voice, reference it — don't redefine it.
- Every rule has an example. A rule without an example is unenforceable. Include either visual examples or explicit do/don't text examples.
- Don't pad. Brand books are skimmed. Cut anything that doesn't help a designer or writer make a decision.
- The "don't" list is mandatory. Every section (logo, colour, type, imagery, voice) must have a "do not" list. The forbidden examples are often more useful than the approved ones.
- Markdown-first. Output is markdown structured for both screen and PDF export. Do not produce binary formats.
- Australian English. "Colour", "organise", "behaviour."
- Reference upstream skill outputs explicitly. If
color-palette produced the palette, reference its file. If design-tokens produced the token system, link to it.
- Voice of the brand book is itself on-brand. A brand book that writes in casual voice for a serious brand fails its own test.
- Numbered sections. Use numbered sections (not just headings) so the document can be cited section-by-section.
Edge Cases
- No upstream skill outputs exist → Recommend running
brand-identity, color-palette, and design-tokens first. Or, accept user-provided equivalents and treat them as inputs.
- Brand has multiple sub-brands or product lines → Document a master brand book with sub-brand rules as a separate section. Don't try to merge identities.
- Existing brand book exists and is being updated → Audit the existing book first. Identify what's still working, what's contradicted by new decisions, and what needs to go. Produce the new book with a "What's Changed" appendix.
- Brand uses outsourced creative consistently → Lean into rule density and explicit examples. The brand book is the only thing the outsourced team will reference.
- Brand is in a regulated category → Add a regulatory section noting any compliance constraints (medical, financial advice, gambling) that affect copy, claims, or imagery.
- Brand is global → Note language and cultural variations. The book should specify which rules are universal and which flex per region.
- Brand is small (1–2 person team) → Keep the book lean. A 100-page book for a 2-person team is overkill. Aim for the minimum useful set of rules.
