brand
MANDATORY PREPARATION
Invoke /product-thinking — it contains product principles and the Context Gathering Protocol. Follow the protocol before proceeding — if no product context exists yet, you MUST run /teach-acumen first.
Mindset: A brand is a contract with the people you serve, expressed in design decisions. DESIGN.md makes that contract legible to coding agents so UI work stays consistent without re-prompting. Tokens give agents exact values; prose tells them why those values exist.
DESIGN.md follows the Google DESIGN.md spec. It lives at the project root (not in .acumen/) and IS checked in — it's a contract, not gitignored context.
Behavior
When called with a section argument (colors, typography, components, spacing, rounded): Update only that section. Ask the user what changed and why.
When called without argument or with all: Full scan and refresh. Build from existing styles outward, not from a blank template.
Research Process
- Read
.acumen.mdfor product context — positioning, audience, brand voice cues - Read existing
DESIGN.mdif it exists - Scan the codebase for source-of-truth styles:
tailwind.config.{js,ts}—theme.extendcolors, fontFamily, spacing, borderRadiusapp/globals.css/src/styles/*.css— CSS custom properties (--color-*,--font-*)- Component primitives (Button, Card, Input) — extract token usage patterns
- Any existing design tokens file (
tokens.json,tokens.css)
- Read brand prose if available — README, marketing site copy, brand guidelines doc
- For each token category, capture both the value and the rationale:
- Colors — primary, secondary, tertiary, neutral; what each is for, not just what it is
- Typography — heading scale, body, captions; voice the type carries (authority, warmth, precision)
- Spacing & rounded — rhythm and softness; what the system feels like
- Components — map composite tokens (button-primary, button-primary-hover) to primitives via references like
{colors.tertiary}
If no source-of-truth styles exist, flag it and ask the user — do not invent tokens.
Output
Write to ./DESIGN.md (project root):
---
name: [Brand or Product Name]
colors:
primary: "#..."
secondary: "#..."
tertiary: "#..."
neutral: "#..."
typography:
h1:
fontFamily: [family]
fontSize: [rem]
body-md:
fontFamily: [family]
fontSize: 1rem
rounded:
sm: 4px
md: 8px
spacing:
sm: 8px
md: 16px
components:
button-primary:
backgroundColor: "{colors.tertiary}"
textColor: "{colors.on-tertiary}"
rounded: "{rounded.sm}"
padding: 12px
---
## Overview
One paragraph capturing the visual posture — what the UI evokes, who it's for, what it deliberately is *not*.
## Colors
For each color: the role it plays, when to use it, when not to. Anchor to the primary user moment it serves.
## Typography
The voice the type carries. What hierarchy decisions do, not just what they look like.
## Layout & Spacing
The rhythm of the system. Why these spacing steps and not others.
## Components
For each component: the interaction it represents and why the token composition reinforces that.
## Do's and Don'ts
Specific traps tied to *this* brand — not generic UI advice.
Follow the canonical section order: Overview → Colors → Typography → Layout & Spacing → Elevation → Shapes → Components → Do's and Don'ts.
Validation
After writing, suggest the user run:
npx @google/design.md lint DESIGN.md
Surface any errors or warnings and offer to fix them. Common issues: broken token refs ({colors.x} resolving to nothing), missing primary, contrast ratios below WCAG AA.
Maintenance
When refreshing:
- Reconcile against current
tailwind.config/ CSS variables — flag drift between code andDESIGN.md - Remove orphaned color tokens (defined but never referenced by a component)
- Re-check component contrast pairs after color changes
NEVER:
- Invent tokens that don't exist in the codebase —
DESIGN.mdis a description of reality, not a wishlist - Describe colors without hex values, or fonts without families — prose alone is not a token
- Treat brand as decoration — every token decision should tie back to who the product serves and what it stands for
- Duplicate Acumen context —
DESIGN.mdis visual identity only; voice, positioning, and persona belong in.acumen.mdand.acumen/personas.md - Add sections outside the canonical order without good reason
More from vgrss/acumen
features
Build and maintain a lightweight feature inventory. Use after shipping, when planning, or to understand the current product surface.
8measure
Check KPI health — what's working, what's not, where to dig deeper. Suggests /workshop for opportunities. Use for metric reviews, health checks, or when something feels off in the numbers.
8diagnose
Find current problems in the product based on data, value delivery for main personas, and current features. Suggests /workshop for ideation on solutions.
8scout
Build and maintain a living competitor map. Supports both quick scans and deep competitive analysis. Use when entering a new market, a competitor launches something, before scoping a feature, or for strategic positioning decisions.
8persona
Build and maintain behavioral personas grounded in real user patterns. Use when launching, after user research, or when user understanding feels stale.
8critique-product
Evaluate and validate a PM artifact — score for rigor, test riskiest assumptions, and decide if it's ready to ship. Use when reviewing a PRD, spec, increment, strategy, or roadmap.
8