// Create a design brief through an interactive interview, codebase exploration, and experience design decisions. Saved as a markdown file in the project. Use when user wants to write a design brief, plan a new feature or page, define a UI direction, or mentions "brief".
| name | design-brief |
| description | Create a design brief through an interactive interview, codebase exploration, and experience design decisions. Saved as a markdown file in the project. Use when user wants to write a design brief, plan a new feature or page, define a UI direction, or mentions "brief". |
This skill creates a design brief through structured conversation. You may skip steps if they are not necessary.
Ask the user for a detailed description of what they want to build, who it is for, and any constraints or ideas they already have.
Explore the existing codebase to understand the current state. Scan for each of the following specifically:
tokens.css, variables.css, theme.css, or :root declarations with custom propertiestailwind.config.js or tailwind.config.ts, check theme.extend for custom valuescreateTheme, Chakra extendTheme, shadcn globals.css and components.jsoncomponents/, ui/, shared/, or any folder containing reusable UI pieces.storybook/ directory or *.stories.* files indicating a documented component library@font-face declarations, font imports in CSS/configInterview the user relentlessly about every aspect of the design until you reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one by one. For each question, provide your recommended answer.
Cover at minimum:
Once you have a complete understanding, write the brief using the template below.
Save the brief to .design/<feature-slug>/DESIGN_BRIEF.md where <feature-slug> is a short, lowercase, hyphenated name derived from the feature or page being designed (e.g., onboarding-flow, settings-page, project-dashboard).
This folder structure ensures that running the design flow multiple times for different features does not overwrite previous work. All subsequent skills (information-architecture, design-tokens, brief-to-tasks, design-review) will read from and write to this same subfolder.
Example:
.design/
├── onboarding-flow/
│ └── DESIGN_BRIEF.md
└── settings-page/
└── DESIGN_BRIEF.md
# Design Brief: [Feature/Page Name]
## Problem
What problem is the user facing, described from their perspective. Not technical. Not business metrics. The human friction.
## Solution
What this interface does to solve that problem, described as an experience, not a feature list.
## Experience Principles
Three principles maximum that guide every design decision. Each principle should resolve a tension.
Example: "Progressive disclosure over upfront complexity" or "Confidence over speed."
1. [Principle] -- [What this means in practice]
2. [Principle] -- [What this means in practice]
3. [Principle] -- [What this means in practice]
## Aesthetic Direction
- **Philosophy**: [Named philosophy or described vibe. See /frontend-design skill for reference.]
- **Tone**: [Emotional register]
- **Reference points**: [Existing products, sites, or styles this should feel like]
- **Anti-references**: [What this should NOT feel like]
## Existing Patterns
Components, tokens, and conventions already in the codebase that this design must respect or extend.
- Typography: [what is currently used]
- Colors: [current palette/variables]
- Spacing: [current scale]
- Components: [existing components that will be reused or extended]
## Component Inventory
A list of the UI components this feature requires. For each, note whether it exists already, needs modification, or is new.
| Component | Status | Notes |
| --------- | --------------------- | -------- |
| [name] | Exists / Modify / New | [detail] |
## Key Interactions
The critical interaction patterns. Describe what the user does and what the interface does in response. Focus on state changes, transitions, and feedback.
## Responsive Behavior
How the layout adapts across breakpoints. Note any components that change behavior (not just size) on mobile.
## Accessibility Requirements
Minimum requirements for this interface. Include contrast ratios, keyboard navigation, screen reader considerations, and focus management.
## Out of Scope
Things this brief explicitly does not cover. Be specific. This prevents scope creep during build.
Run the full design-to-build workflow as a guided sequence. Orchestrates all designer skills in order, from grilling through review. Use when user wants to go through the complete design process, start a project from scratch, run the full flow, or mentions "design flow" or "full workflow".
Run a structured design critique against the brief and codebase. Checks visual hierarchy, consistency, responsiveness, accessibility, and aesthetic fidelity. Use when user wants a design review, critique, QA pass, polish pass, or mentions "review" after building.
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, challenge an approach, or mentions "grill me".
Break a design brief into an ordered checklist of independently buildable tasks using vertical slices. Saves as a markdown checklist. Use when user wants to break down work, create tasks from a brief, plan implementation order, or mentions "tasks" or "breakdown".
Generate a design tokens file (CSS variables or Tailwind config) based on a chosen aesthetic philosophy, with light and dark mode palettes, spacing scale, type ramp, and component-level tokens. Use when starting a new project, establishing a visual system, setting up tokens, or mentions "tokens" or "design system".
Define the structural layer of a product or site before visual design begins. Covers navigation, content hierarchy, page structure, URL patterns, and user flows. Use when user wants to plan site structure, define navigation, map user flows, organize content, or mentions "IA" or "information architecture".