design-brief

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

This skill creates a design brief through structured conversation. You may skip steps if they are not necessary.

本Skill通过结构化对话生成设计简报，非必要步骤可跳过。

Example prompts

示例提示词

"Write a brief for the onboarding flow"
"I need to plan a settings page before I start building"
"Help me define the direction for a marketing landing page"
"Brief this: a dashboard that shows project health metrics"

"为用户入门流程撰写一份简报"
"我需要在开始开发前先规划设置页面"
"帮我确定营销落地页的设计方向"
"给这个做个简报：展示项目健康指标的仪表盘"

Process

流程

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:
- CSS variables / tokens: files named
```
tokens.css
```
  ,
```
variables.css
```
  ,
```
theme.css
```
  , or
```
:root
```
  declarations with custom properties
- Tailwind config:
```
tailwind.config.js
```
  or
```
tailwind.config.ts
```
  , check
```
theme.extend
```
  for custom values
- UI framework themes: Material UI
```
createTheme
```
  , Chakra
```
extendTheme
```
  , shadcn
```
globals.css
```
  and
```
components.json
```
- Component directories:
```
components/
```
  ,
```
ui/
```
  ,
```
shared/
```
  , or any folder containing reusable UI pieces
- Storybook:
```
.storybook/
```
  directory or
```
*.stories.*
```
  files indicating a documented component library
- Design token files: JSON token files (Style Dictionary format, Figma token exports)
- Package.json UI dependencies: tailwindcss, @mui/material, @chakra-ui/react, @radix-ui, lucide-react, framer-motion, etc.
- Font loading: Google Fonts links in HTML,
```
@font-face
```
  declarations, font imports in CSS/config
- Existing pages/layouts: route files, layout components, page templates that show established patterns
- If components exist, treat them as the starting vocabulary. The brief should extend, not replace.
Interview 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:
- Who is the primary user their JTBD and what are they trying to accomplish?
- What does success look like for this interface?
- What is the emotional tone? (calm, urgent, playful, authoritative, warm, clinical)
- What existing products, sites, or styles should this feel like? What should it NOT feel like?
- What are the hard constraints? (devices, accessibility requirements, performance budgets, brand guidelines)
- What content will this interface contain? What is placeholder vs. real?
Once you have a complete understanding, write the brief using the template below.

询问用户关于他们想要开发的内容的详细描述、目标受众，以及已有的约束条件或想法。
探索现有代码库以了解当前状态，重点扫描以下内容：
- CSS变量 / 设计令牌：名为
```
tokens.css
```
  、
```
variables.css
```
  、
```
theme.css
```
  的文件，或是带有自定义属性的
```
:root
```
  声明
- Tailwind配置：
```
tailwind.config.js
```
  或
```
tailwind.config.ts
```
  ，查看
```
theme.extend
```
  中的自定义值
- UI框架主题：Material UI
```
createTheme
```
  、Chakra
```
extendTheme
```
  、shadcn
```
globals.css
```
  和
```
components.json
```
- 组件目录：
```
components/
```
  、
```
ui/
```
  、
```
shared/
```
  ，或是任何包含可复用UI模块的文件夹
- Storybook：
```
.storybook/
```
  目录或
```
*.stories.*
```
  文件，说明存在文档化的组件库
- 设计令牌文件：JSON令牌文件（Style Dictionary格式、Figma令牌导出文件）
- Package.json UI依赖：tailwindcss, @mui/material, @chakra-ui/react, @radix-ui, lucide-react, framer-motion等
- 字体加载：HTML中的Google Fonts链接、
```
@font-face
```
  声明、CSS/配置中的字体导入
- 现有页面/布局：路由文件、布局组件、页面模板，这些展示了已确立的模式
- 如果已有组件，将它们作为基础词汇，设计简报应当扩展而非替换现有组件。
就设计的各个方面反复与用户沟通，直到双方达成共识。梳理设计决策的各个分支，逐一解决决策之间的依赖关系。每个问题都要给出你推荐的答案。

至少覆盖以下内容：
- 核心用户是谁，他们的JTBD是什么，他们想要达成什么目标？
- 这个界面的成功标准是什么？
- 情感基调是什么？（平静、紧迫、活泼、权威、温暖、冷静客观）
- 应该参考哪些现有产品、网站或风格？应该避免哪些风格？
- 硬性约束有哪些？（设备、无障碍要求、性能预算、品牌指南）
- 这个界面包含哪些内容？哪些是占位符，哪些是真实内容？
当你完全理解需求后，使用下方模板撰写简报。

File Output

文件输出

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/<feature-slug>/DESIGN_BRIEF.md

，其中

<feature-slug>

是根据待设计的功能或页面生成的简短、小写、连字符分隔的名称（例如

onboarding-flow

、

settings-page

、

project-dashboard

）。

这种文件夹结构可以确保为不同功能多次运行设计流程时不会覆盖之前的工作。所有后续Skill（信息架构、设计令牌、简报转任务、设计评审）都会读写同一个子文件夹。

示例：

.design/
├── onboarding-flow/
│   └── DESIGN_BRIEF.md
└── settings-page/
    └── DESIGN_BRIEF.md

Brief Template

简报模板

markdown

undefined

markdown

undefined

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."

[Principle] -- [What this means in practice]
[Principle] -- [What this means in practice]
[Principle] -- [What this means in practice]

Three principles maximum that guide every design decision. Each principle should resolve a tension. Example: "Progressive disclosure over upfront complexity" or "Confidence over speed."

[Principle] -- [What this means in practice]
[Principle] -- [What this means in practice]
[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]

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]

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]

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.

undefined

Things this brief explicitly does not cover. Be specific. This prevents scope creep during build.

undefined