design-brief

此技能通过结构化对话创建设计简报。如有些步骤并非必要，你可以跳过。

示例提示词

• “为入门流程编写一份简报”
• “我需要在开始构建之前规划一个设置页面”
• “帮我确定营销落地页的设计方向”
• “为这个项目编写简报：一个展示项目健康度指标的仪表板”

流程

1. 请用户详细描述他们想要构建什么、面向哪些用户，以及他们已有的任何约束或想法。

2. 探索现有代码库，了解当前状态。特别扫描以下内容：

   • 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 / 配置中的字体导入
   • 现有页面 / 布局：路由文件、布局组件、页面模板，用于了解已有模式
   • 如果存在组件，应将其视为起始设计词汇。简报应在此基础上扩展，而非取而代之。

3. 针对设计的每个方面，持续深入地采访用户，直到双方达成共识。逐步梳理设计树中的每个分支，逐一厘清决策之间的依赖关系。每个问题都要提供你的推荐答案。

   至少涵盖：

   • 谁是主要用户？他们的 JTBD 是什么？他们想要完成什么？
   • 对此界面而言，什么样的结果才算成功？
   • 情感基调是什么？（沉静、紧迫、活泼、权威、温暖、冷静）
   • 应该让人联想到哪些现有产品、网站或风格？又不应该是什么感觉？
   • 有哪些硬性约束？（设备、无障碍要求、性能预算、品牌指南）
   • 此界面将包含哪些内容？哪些是占位内容，哪些是真实内容？

4. 完全了解需求后，使用下方模板编写简报。

文件输出

将简报保存到 .design/<feature-slug>/DESIGN_BRIEF.md，其中 <feature-slug> 是根据要设计的功能或页面生成的简短、小写、连字符分隔的名称（例如：onboarding-flow、settings-page、project-dashboard）。

此文件夹结构可确保多次针对不同功能运行设计流程时，不会覆盖之前的工作。之后的所有技能（information-architecture、design-tokens、brief-to-tasks、design-review）都会从同一子文件夹读取和写入文件。

示例：

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