AI Skills
design-brief

design-brief

热门

通过交互式访谈、代码库探索和体验设计决策创建设计简报。以 Markdown 文件形式保存在项目中。当用户想要编写设计简报、规划新功能或页面、定义 UI 方向或提及“简报”时使用。

435Star
34Fork
更新于 2026/7/6
获取 Skill源代码

相关 Skills

design11万algorithmic-art15万frontend-ui-engineering7.7万
SKILL.md
readonly只读
name
design-brief
description

通过交互式访谈、代码库探索和体验设计决策创建设计简报。以 Markdown 文件形式保存在项目中。当用户想要编写设计简报、规划新功能或页面、定义 UI 方向或提及“简报”时使用。

此技能通过结构化对话创建设计简报。如果某些步骤不必要，可以跳过。

示例提示

  • "为引导流程写一份简报"
  • "我需要先规划设置页面再开始构建"
  • "帮我定义营销着陆页的方向"
  • "简报：一个显示项目健康指标的仪表盘"

流程

  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）。

此文件夹结构确保为不同功能多次运行设计流程不会覆盖之前的工作。所有后续技能（信息架构、设计令牌、简报到任务、设计评审）都将读取并写入同一子文件夹。

示例：

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

简报模板

# 设计简报：[功能/页面名称]

## 问题

用户面临的问题，从他们的角度描述。不是技术问题。不是业务指标。而是人的摩擦点。

## 解决方案

此界面如何解决该问题，描述为一种体验，而非功能列表。

## 体验原则

最多三条原则，指导每个设计决策。每条原则应解决一个张力。
示例："渐进式披露优于一次性复杂性"或"信心优于速度。"

1. [原则] -- [在实践中意味着什么]
2. [原则] -- [在实践中意味着什么]
3. [原则] -- [在实践中意味着什么]

## 美学方向

- **理念**：[命名的理念或描述的氛围。参考 /frontend-design 技能。]
- **基调**：[情感基调]
- **参考点**：[应该感觉像哪些现有产品、网站或风格]
- **反参考**：[不应该感觉像什么]

## 现有模式

代码库中已有的组件、令牌和约定，此设计必须尊重或扩展。

- 排版：[当前使用的]
- 颜色：[当前调色板/变量]
- 间距：[当前比例]
- 组件：[将被复用或扩展的现有组件]

## 组件清单

此功能所需的 UI 组件列表。对于每个组件，注明是已存在、需要修改还是新建。

| 组件 | 状态                | 备注    |
| ---- | ------------------- | ------- |
| [名称] | 已存在 / 修改 / 新建 | [详情] |

## 关键交互

关键的交互模式。描述用户做什么以及界面如何响应。关注状态变化、过渡和反馈。

## 响应式行为

布局如何在不同断点下适配。注意在移动端改变行为（不仅仅是尺寸）的组件。

## 无障碍要求

此界面的最低要求。包括对比度、键盘导航、屏幕阅读器考虑和焦点管理。

## 范围外

此简报明确不涵盖的内容。要具体。这可以防止构建过程中的范围蔓延。