wtf.design-feature

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Design Feature

设计功能

Pick up a Feature as a designer and produce a holistic design covering the full user journey before tasks are cut. Core value: maps every user story to screens and states, identifies shared components across the feature, and writes a complete Design Handoff back into the Feature issue — so

feature-to-tasks

can derive better tasks and

design-task

inherits feature-level decisions rather than reinventing them.

作为设计师承接一项Feature，在拆分任务前生成覆盖完整用户旅程的整体设计。核心价值：将每个用户故事映射到界面和状态，识别Feature内的共享组件，并在Feature议题中撰写完整的设计交付文档——这样

feature-to-tasks

可以拆分出更合理的任务，

design-task

也能继承Feature层面的决策，无需重新设计。

Process

流程

0. GitHub CLI setup

0. GitHub CLI 配置

Run steps 1–2 of

../references/gh-setup.md

(install check and auth check). Stop if

gh

is not installed or not authenticated. Extensions are not required for this skill.

Skip this step if invoked from another skill that already ran gh-setup this session.

运行

../references/gh-setup.md

中的步骤1–2（安装检查和身份验证检查）。如果未安装

gh

或未完成身份验证，请停止。此技能不需要扩展。

如果是由本次会话中已运行gh-setup的其他技能调用，则跳过此步骤。

1. Identify the Feature

1. 确定Feature

If the user provided an issue number in their request, use it directly. Otherwise search for recent open issues with label

feature

to populate options and call

AskUserQuestion

with

question: "Which Feature are you designing?"

header: "Feature"

, and

options

pre-filled with 1–2 likely open Feature issue references.

Fetch the Feature and its parent Epic:

bash

gh issue view <feature_number>    # User stories, ACs, Edge Cases, Domain Events

如果用户在请求中提供了议题编号，直接使用该编号。否则搜索最近带有

feature

标签的开放议题，生成选项后调用

AskUserQuestion

，参数为

question: "你要设计哪项Feature？"

，

header: "Feature"

，并预填充1–2个可能的开放Feature议题引用作为

options

。

获取Feature及其所属Epic：

bash

gh issue view <feature_number>    # 用户故事、验收标准、边缘案例、领域事件

Extract epic number from Context section, then:

从Context部分提取epic编号，然后执行：

gh issue view <epic_number> # Goal, Context, Design Artifacts (strategic input)


Extract and hold in context:
- Feature capability name (Actor + verb + object)
- All user stories
- All Acceptance Criteria
- Edge Cases
- Domain Events (emitted/consumed)
- Epic's Design Artifacts (any Figma links or research docs — these are upstream constraints)

gh issue view <epic_number> # 目标、背景、设计工件（战略输入）


提取并保存以下内容到上下文：
- Feature能力名称（角色 + 动作 + 对象）
- 所有用户故事
- 所有验收标准
- 边缘案例
- 领域事件（触发/消费）
- Epic的设计工件（任何Figma链接或研究文档——这些是上游约束）

2. Lifecycle check

2. 生命周期检查

Check whether the feature already has a

designed

label:

bash

gh issue view <feature_number> --json labels --jq '.labels[].name'

designed

is present, call

AskUserQuestion

with:

```
question
```
: "This Feature already has a
```
designed
```
label. Continuing will overwrite the existing Design Handoff. How would you like to proceed?"
```
header
```
: "Already designed"

options

[{label: "Redesign it", description: "Overwrite the existing Design Handoff with a new one"}, {label: "Exit", description: "Leave the existing design as-is"}]

Redesign it → continue.
Exit → exit immediately.

If absent, continue silently.

检查该Feature是否已有

designed

标签：

bash

gh issue view <feature_number> --json labels --jq '.labels[].name'

如果存在

designed

标签，调用

AskUserQuestion

，参数如下：

```
question
```
: "此Feature已有
```
designed
```
标签。继续操作将覆盖现有的设计交付文档。你希望如何处理？"
```
header
```
: "已完成设计"

options

[{label: "重新设计", description: "用新的设计交付文档覆盖现有内容"}, {label: "退出", description: "保留现有设计不变"}]

重新设计 → 继续流程。
退出 → 立即终止操作。

如果不存在该标签，直接继续流程。

3. Load the design steering document

3. 加载设计指导文档

Use the Read tool to attempt reading

docs/steering/DESIGN.md

If it exists: keep its content in context. Apply its design principles, tokens, component patterns, and accessibility standards silently throughout this session.

If it does not exist, call

AskUserQuestion

with:

```
question
```
: "docs/steering/DESIGN.md doesn't exist yet. This document captures your design principles, tokens, and component patterns. Would you like to create it now?"
```
header
```
: "Design steering doc missing"

options

[{label: "Create it now", description: "Run steer-design before continuing (recommended)"}, {label: "Skip for this session", description: "Continue without it — design decisions won't reference project standards"}]

Create it now → follow the
```
steer-design
```
process, then return here and continue from step 4.
Skip for this session → continue without it.

使用Read工具尝试读取

docs/steering/DESIGN.md

。

如果存在：将其内容保存到上下文。在本次会话中全程遵循其中的设计原则、设计令牌、组件模式和无障碍标准。

如果不存在，调用

AskUserQuestion

，参数如下：

```
question
```
: "docs/steering/DESIGN.md 不存在。该文档用于记录你的设计原则、设计令牌和组件模式。你是否要现在创建它？"
```
header
```
: "缺失设计指导文档"

options

[{label: "现在创建", description: "先执行steer-design流程，再继续（推荐）"}, {label: "本次会话跳过", description: "直接继续——设计决策不会参考项目标准"}]

现在创建 → 执行
```
steer-design
```
流程，完成后返回此处从步骤4继续。
本次会话跳过 → 直接继续流程。

4. Explore the design system and codebase

4. 探索设计系统和代码库

Use the Agent tool with these searches (run in parallel):

```
Glob('src/components/**/*', 'src/**/components/**/*', 'components/**/*')
```
— existing UI components; flag any that map to domain objects in this Feature's user stories

Glob('**/{tokens,theme,variables,design-tokens}.{css,scss,ts,js,json}')

— design tokens

```
Glob('src/**/*.{stories,story}.{ts,tsx,js,jsx,mdx}')
```
— Storybook stories as pattern references for similar flows
```
Grep
```
for
```
figma.com
```
URLs across
```
.md
```
,
```
.mdx
```
files — existing Figma references in related issues or docs

Note which existing components can be reused vs which are new. This feeds step 7.

使用Agent工具并行执行以下搜索：

```
Glob('src/components/**/*', 'src/**/components/**/*', 'components/**/*')
```
— 现有UI组件；标记出与该Feature用户故事中领域对象匹配的组件

Glob('**/{tokens,theme,variables,design-tokens}.{css,scss,ts,js,json}')

— 设计令牌

```
Glob('src/**/*.{stories,story}.{ts,tsx,js,jsx,mdx}')
```
— Storybook案例，作为类似流程的模式参考
```
Grep
```
搜索
```
.md
```
、
```
.mdx
```
文件中的
```
figma.com
```
链接 — 相关议题或文档中的现有Figma引用

记录哪些现有组件可复用，哪些需要新增。此信息将用于步骤7。

5. Map the full user journey

5. 映射完整用户旅程

For each user story ("As a [Actor], I want [action] so that [outcome]"), derive:

Entry point — what triggers this story? (screen, action, event)
Happy path screens — ordered list of screens/states the actor moves through
Branch states — loading, error, empty, partial data, permission denied
Exit point — what confirms the story is complete for the actor?

Also map:

Cross-story transitions — screens shared between multiple user stories
Edge case screens — one screen per Edge Case from the Feature issue
Domain Event surfaces — where in the UI does each emitted Domain Event become visible to the actor?

Produce a journey map as a structured list — do not ask the user, derive from user stories and ACs.

针对每个用户故事（“作为[角色]，我希望[动作]以实现[结果]”），推导：

入口点 — 触发该故事的条件？（界面、动作、事件）
主流程界面 — 用户依次经过的界面/状态有序列表
分支状态 — 加载中、错误、空状态、部分数据、权限拒绝
出口点 — 什么标志着用户完成了该故事？

同时映射：

跨故事过渡 — 多个用户故事共享的界面
边缘案例界面 — 每个Feature议题中的边缘案例对应一个界面
领域事件展示 — 每个触发的领域事件在UI中的哪个位置对用户可见？

生成结构化列表形式的旅程图——无需询问用户，直接从用户故事和验收标准推导。

6. Ask about design assets

6. 询问设计资产处理方式

Call

AskUserQuestion

with

question: "How would you like to handle designs for this feature?"

header: "Design assets"

, and

options

{label: "I have Figma frames", description: "Provide frame URLs — I'll validate coverage against the full journey map"}

{label: "Generate designs for me", description: "I'll use Figma MCP to generate frames from the user stories and design system"}

{label: "Scaffold a brief only", description: "No Figma — produce a text screen inventory and component map"}

{label: "Partial — some screens designed", description: "Provide available frames; remaining screens go to generate or scaffold"}

Path A — Human provides frames: Collect the top-level Figma file URL plus individual frame URLs. For each screen in the journey map (step 5), check whether a frame covers it. Present a coverage matrix: screen → frame URL (or ⚠ gap). If gaps exist, call

AskUserQuestion

asking whether to generate missing frames (Path B) or leave them as pending.

Also validate provided frames against spec:

Every user story has at least one matching frame
Every edge case from the Feature issue has a matching error/boundary state frame
Every Domain Event surface identified in step 5 is represented

Flag any validation failures as gaps in the coverage matrix.

Path B — AI generates via Figma MCP: Check whether the Figma MCP tool

generate_figma_design

is available. If unavailable, warn the user and fall back to Path C (scaffold).

If available: for each screen in the journey map without a frame, call

generate_figma_design

with:

The screen's user story and entry/exit points as the design brief
Component patterns and tokens from
```
docs/steering/DESIGN.md
```
(loaded in step 3)
Shared components identified in step 7 as reuse constraints
Any Figma URLs from the Epic's Design Artifacts as style reference

Collect the generated frame URLs and treat them as Path A frames for the coverage matrix and Design Handoff.

Path C — Scaffold brief only: For each screen in the journey map, produce a text brief listing required UI elements, interactions, and relevant design tokens. This is a Figma-free design brief a designer or developer can execute against. Use

references/component-spec-template.md

as the structure if available.

Partial: Collect available frame URLs, run Path A validation on covered screens. For uncovered screens, call

AskUserQuestion

asking whether to generate (Path B) or scaffold (Path C) the remainder.

调用

AskUserQuestion

，参数为

question: "你希望如何处理此Feature的设计？"

，

header: "设计资产"

，以及以下

options

：

{label: "我已有Figma框架", description: "提供框架链接——我会对照完整旅程图验证覆盖范围"}

{label: "为我生成设计", description: "我将使用Figma MCP根据用户故事和设计系统生成框架"}

{label: "仅生成设计大纲", description: "无需Figma——生成文本形式的界面清单和组件映射"}

{label: "部分完成——已有部分界面设计", description: "提供已有的框架链接；剩余界面选择生成或大纲模式"}

路径A — 用户提供框架： 收集顶层Figma文件链接及单个框架链接。对照旅程图（步骤5）中的每个界面，检查是否有对应的框架。生成覆盖矩阵：界面 → 框架链接（或⚠ 缺失）。如果存在缺失，调用

AskUserQuestion

询问是否生成缺失框架（路径B）或标记为待完成。

同时验证提供的框架是否符合规范：

每个用户故事至少有一个匹配的框架
Feature议题中的每个边缘案例都有对应的错误/边界状态框架
步骤5中识别的每个领域事件展示位置都有对应框架

将验证失败的项标记为覆盖矩阵中的缺失项。

路径B — 通过Figma MCP生成： 检查Figma MCP工具

generate_figma_design

是否可用。如果不可用，向用户发出警告并 fallback 到路径C（生成大纲）。

如果可用：针对旅程图中没有框架的每个界面，调用

generate_figma_design

，参数包括：

界面的用户故事及入口/出口点作为设计需求
```
docs/steering/DESIGN.md
```
中的组件模式和设计令牌（步骤3加载）
步骤7中识别的共享组件作为复用约束
Epic设计工件中的任何Figma链接作为风格参考

收集生成的框架链接，并将其视为路径A的框架，用于覆盖矩阵和设计交付文档。

路径C — 仅生成设计大纲： 针对旅程图中的每个界面，生成文本形式的设计大纲，列出所需UI元素、交互逻辑和相关设计令牌。这是无需Figma的设计需求文档，设计师或开发者可据此执行。如果

references/component-spec-template.md

存在，以此为结构生成。

部分完成： 收集已有的框架链接，对已覆盖的界面执行路径A的验证。针对未覆盖的界面，调用

AskUserQuestion

询问是生成（路径B）还是生成大纲（路径C）。

7. Identify shared components

7. 识别共享组件

Across all screens in the journey map, identify:

Reused existing components — already in the codebase (found in step 4); list component path + which screens use it
New shared components — appear on 2+ screens but do not exist yet; name them using domain language
Screen-specific components — appear on only one screen; note them but do not detail here (that is
```
design-task
```
's job)

This component map reduces duplication when

design-task

runs per-task.

遍历旅程图中的所有界面，识别：

可复用现有组件 — 已存在于代码库中（步骤4找到）；列出组件路径及使用该组件的界面
新增共享组件 — 在2个及以上界面出现但尚未存在；使用领域语言命名
界面专属组件 — 仅在一个界面出现；记录但无需详细描述（这是
```
design-task
```
的工作）

此组件映射可减少

design-task

按任务执行时的重复工作。

8. Draft the Design Handoff

8. 撰写设计交付文档草稿

Produce content for the Design Handoff section of the Feature issue:

markdown

undefined

为Feature议题的Design Handoff部分生成内容：

markdown

undefined

Design Handoff

Figma: <top-level Figma file URL, generated file URL, or "pending (scaffold only)">
Flow: <link to prototype/flow if available>
Design path: <Path A: human-provided | Path B: AI-generated | Path C: scaffold brief>

Figma: <顶层Figma文件链接、生成的文件链接，或"待完成（仅大纲）">
流程: <原型/流程链接（如有）>
设计路径: <路径A: 用户提供 | 路径B: AI生成 | 路径C: 大纲文档>

Screen inventory

界面清单

Screen	Story	Figma frame	States covered	Source
<screen name>	As a...	<url or pending>	default / loading / error / empty	provided / generated / scaffolded

界面	用户故事	Figma框架	覆盖状态	来源
<界面名称>	作为...	<链接或待完成>	默认 / 加载中 / 错误 / 空状态	用户提供 / AI生成 / 大纲

Validation (Path A/B only)

验证（仅路径A/B）

Every user story has ≥1 frame
Every edge case has a boundary/error state frame
Every Domain Event surface is represented
All frames consistent with DESIGN.md tokens and patterns

每个用户故事至少有1个框架
每个边缘案例都有对应的边界/错误状态框架
每个领域事件展示位置都有对应框架
所有框架符合DESIGN.md的令牌和模式

Shared components

共享组件

Component	Exists?	Path or new	Used on
<name>	yes/no	<path or "new">	<screens>

组件	是否存在？	路径或新增	使用界面
<名称>	是/否	<路径或"新增">	<界面列表>

Accessibility notes

无障碍说明

<来自指导文档或Epic的Feature层面无障碍约束>

Open gaps

未完成项

undefined

<列出尚未设计的界面或状态——待完成的Figma框架>

undefined

9. Review with user

9. 与用户评审

Show the draft. Then call

AskUserQuestion

with

question: "Does this cover the full feature journey?"

header: "Review"

, and

options

{label: "Looks complete — update the issue", description: "Proceed"}

{label: "Missing screens or states", description: "I want to add coverage"}

{label: "Other changes", description: "I want to adjust something"}

Apply edits, then proceed.

展示草稿。然后调用

AskUserQuestion

，参数为

question: "这份文档是否覆盖了完整的Feature旅程？"

，

header: "评审"

，以及以下

options

：

{label: "内容完整——更新议题", description: "继续"}

{label: "缺失界面或状态", description: "我要补充覆盖范围"}

{label: "其他修改", description: "我要调整内容"}

应用修改后继续流程。

10. Update the Feature issue

10. 更新Feature议题

Read the current issue body, replace only the Design Handoff section with the new content, preserve all other sections. Write to temp file and use

--body-file

bash

gh issue edit <feature_number> --body-file /tmp/wtf-design-feature-body.md

Add the

designed

label when either:

Path A/B: all screens in the journey map have Figma frames (no open gaps in coverage matrix), or
Path C: the full scaffold brief is complete (no Figma expected)

bash

gh issue edit <feature_number> --add-label "designed"

If Path A/B has open gaps, do not add

designed

— note it will be added once gaps are closed.

This fulfills the Feature DoR gate: "Design handoff complete".

Print the updated Feature issue URL.

读取当前议题内容，仅替换Design Handoff部分为新内容，保留其他所有部分。写入临时文件并使用

--body-file

：

bash

gh issue edit <feature_number> --body-file /tmp/wtf-design-feature-body.md

在以下情况之一时添加

designed

标签：

路径A/B：旅程图中的所有界面都有Figma框架（覆盖矩阵无未完成项），或
路径C：完整的大纲文档已生成（无需Figma）

bash

gh issue edit <feature_number> --add-label "designed"

如果路径A/B存在未完成项，不要添加

designed

标签——注明待完成项填补后再添加。

这满足Feature的DoR准入标准：“设计交付完成”。

打印更新后的Feature议题链接。

11. Offer to continue

11. 提供后续操作选项

Call

AskUserQuestion

with:

```
question
```
: "What's next?"
```
header
```
: "Next step"

options

{label: "Break into Tasks", description: "Run feature-to-tasks — design context will inform task breakdown (default)"}

{label: "Design another Feature", description: "Design another Feature for the same Epic"}

{label: "Stop here", description: "Exit — no further action"}

Break into Tasks → follow the
```
feature-to-tasks
```
skill, passing the Feature number in as context. Note to the user that
```
design-task
```
will inherit the shared component map from this Design Handoff.
Design another Feature → restart from step 1, reusing the same Epic context.
Stop here → exit.

调用

AskUserQuestion

，参数如下：

```
question
```
: "下一步操作？"
```
header
```
: "下一步"

options

{label: "拆分为任务", description: "执行feature-to-tasks——设计上下文将指导任务拆分（默认选项）"}

{label: "设计另一项Feature", description: "为同一Epic设计另一项Feature"}

{label: "到此为止", description: "退出——无后续操作"}

拆分为任务 → 执行
```
feature-to-tasks
```
技能，将Feature编号传入上下文。告知用户
```
design-task
```
将从此次设计交付文档中继承共享组件映射。
设计另一项Feature → 从步骤1重新开始，复用相同的Epic上下文。
到此为止 → 退出操作。