brief-to-tasks

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

This skill turns a design brief into an ordered, buildable task list. Each task is a vertical slice: a piece of UI that can be built, reviewed, and verified on its own.

这个Skill可以将设计需求说明书转换为有序的、可开发的任务列表。每个任务都是一个垂直切片：即可以独立开发、评审、验证的UI模块。

Example prompts

示例提示词

"Break the brief into tasks"
"What should I build first?"
"Create a task list from the design brief"
"Plan the build order for this feature"

「将需求说明书拆分为任务」
「我应该先开发什么？」
「根据设计需求说明书生成任务列表」
「规划这个功能的开发顺序」

Process

执行流程

Read the design brief. Look for
```
.design/*/DESIGN_BRIEF.md
```
. If multiple subfolders exist, use the most recently modified one, or ask the user which feature they are working on. Also check for
```
INFORMATION_ARCHITECTURE.md
```
and a tokens file in the same subfolder. If none exist, ask the user to describe what they are building.
Explore the existing codebase to understand what is already built. Scan specifically for:
- Component directories:
```
components/
```
  ,
```
ui/
```
  ,
```
shared/
```
  and list every component by name
- Existing pages/views: what is already built that this feature must coexist with
- Token/theme files:
```
tokens.css
```
  ,
```
globals.css
```
  , Tailwind config, theme providers
- File naming conventions: kebab-case, PascalCase, how files are organized (by feature, by type)
- Test files: if tests exist alongside components, new tasks should include test expectations
- Package.json dependencies: what UI libraries, animation libraries, and icon sets are already installed
- Classify each relevant component as: will be reused as-is, needs modification, or does not exist yet. Only components that need modification or creation get their own tasks.
Break the work into vertical slices. Each task should:
- Be independently buildable (no task should block another unless noted).
- Include structure, styling, and interaction in a single task (not "build HTML" then "add CSS" then "add JS" as separate tasks).
- Be verifiable: you can look at the result and confirm it matches the brief.
- Be small enough to complete in a single session.
Order tasks by:
- Dependencies first: foundational elements (tokens, layout shells, shared components) before page-specific work.
- Visual priority: the most prominent UI element early, so the user can validate the aesthetic direction before investing in details.
- Risk first: the hardest or most uncertain piece early, so problems surface before everything else is built around them.
Save the task list as
```
TASKS.md
```
in the same
```
.design/<feature-slug>/
```
subfolder as the design brief.

读取设计需求说明书，查找
```
.design/*/DESIGN_BRIEF.md
```
文件。如果存在多个子文件夹，使用最近修改的那个，或者询问用户当前正在开发哪个功能。同时检查同个子文件夹下的
```
INFORMATION_ARCHITECTURE.md
```
和 tokens 文件。如果找不到这些文件，请用户描述他们正在开发的内容。
调研现有代码库，了解已完成的内容。重点扫描以下部分：
- 组件目录：
```
components/
```
  、
```
ui/
```
  、
```
shared/
```
  ，列出所有组件的名称
- 现有页面/视图：已开发完成、需要和本次功能共存的内容
- Token/主题文件：
```
tokens.css
```
  、
```
globals.css
```
  、Tailwind 配置、主题提供者
- 文件命名规范：kebab-case、PascalCase、文件的组织方式（按功能/按类型）
- 测试文件：如果组件旁有测试文件，新任务需要包含测试要求
- Package.json 依赖：已安装的 UI 库、动画库、图标集将每个相关组件归类为：直接复用、需要修改、暂不存在。只有需要修改或新建的组件需要单独列为任务。
将工作拆分为垂直切片。每个任务需要满足：
- 可独立开发（除非特别说明，否则任务之间不应该阻塞）。
- 在单个任务中包含结构、样式和交互（不要把「编写 HTML」「添加 CSS」「添加 JS」拆分为独立任务）。
- 可验证：可以通过查看结果确认是否符合需求。
- 粒度足够小，可以在单个工作时段内完成。
任务排序规则：
- 依赖优先：基础元素（tokens、布局框架、共享组件）优先于页面专属内容。
- 视觉优先级：最突出的 UI 元素优先，这样用户可以在投入细节开发前确认美学方向。
- 风险优先：最困难或不确定性最高的部分优先，这样可以在其他所有内容围绕其开发前发现问题。
将任务列表保存为
```
TASKS.md
```
，存储在设计需求说明书所在的
```
.design/<feature-slug>/
```
子文件夹下。

Task List Template

任务列表模板

markdown

undefined

markdown

undefined

Build Tasks: [Feature/Page Name]

Generated from: .design/<feature-slug>/DESIGN_BRIEF.md Date: [date]

Foundation

[Task name]: [One sentence describing what to build and what "done" looks like]. Reuses: [existing components/tokens if any].
[Task name]: [Description]. New component.

[Task name]: [One sentence describing what to build and what "done" looks like]. Reuses: [existing components/tokens if any].
[Task name]: [Description]. New component.

Core UI

[Task name]: [Description]. Depends on: [task name if any].
[Task name]: [Description].

[Task name]: [Description]. Depends on: [task name if any].
[Task name]: [Description].

Interactions & States

[Task name]: [Description]. Covers: [list of states, e.g., hover, loading, error, empty].
[Task name]: [Description].

[Task name]: [Description]. Covers: [list of states, e.g., hover, loading, error, empty].
[Task name]: [Description].

Responsive & Polish

[Task name]: [Description]. Breakpoints: [which ones].
[Task name]: Accessibility pass. [Specific checks from the brief].

[Task name]: [Description]. Breakpoints: [which ones].
[Task name]: Accessibility pass. [Specific checks from the brief].

Review

Design review: Run /design-review against the brief.

undefined

Design review: Run /design-review against the brief.

undefined

Rules

规则

Every task must reference whether it reuses, modifies, or creates components.
Never create a task that is only "set up the project" or "create the file structure." Those are not vertical slices.
If the brief specifies an aesthetic philosophy, note it in the first build task so the visual direction is established immediately.
Group related tasks but do not nest them more than one level deep. Flat lists are easier to work through.

每个任务必须说明是复用、修改还是新建组件。
永远不要创建仅为「搭建项目」或「创建文件结构」的任务，这些不属于垂直切片。
如果需求说明书指定了美学理念，在第一个开发任务中注明，以便立即确立视觉方向。
对相关任务进行分组，但嵌套层级不要超过1层。扁平化列表更便于执行。