Back to Details

frontend-design-ui-ux

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
<EXTREMELY-IMPORTANT> This is a design-spec skill, not an implementation skill.
Non-negotiable rules:
  1. Understand users, context, and states before proposing screens.
  2. Specify flows, states, accessibility, and responsiveness, not just visuals.
  3. Reuse the templates in 
    references/
    instead of inventing new handoff formats.
  4. Keep implementation handoff concrete enough that an engineering agent can build from it.
  5. Do not start coding the UI from this skill.
</EXTREMELY-IMPORTANT>
<EXTREMELY-IMPORTANT> 这是一项设计规范技能，而非实现技能。
不可违背的规则：
  1. 在提出界面设计前，先理解用户、使用场景和状态。
  2. 要明确流程、状态、无障碍要求和响应式表现，而不只是视觉设计。
  3. 复用
    references/
    中的模板，而非创建新的交付格式。
  4. 确保交付的实现指引足够具体，让工程Agent可以直接据此开发。
  5. 不要通过此技能直接编写UI代码。
</EXTREMELY-IMPORTANT>

frontend-design-ui-ux

前端设计-UX/UI

Inputs

输入

  • $request
    : Feature, page, component, or UX problem to design
  • $request
    : 需要设计的功能、页面、组件或UX问题

Goal

目标

Produce a design handoff that covers:
  • user goals
  • flow and state model
  • component structure
  • design tokens
  • accessibility and responsive behavior
  • target engineering handoff
生成涵盖以下内容的设计交付物：
  • 用户目标
  • 流程与状态模型
  • 组件结构
  • 设计令牌
  • 无障碍与响应式表现
  • 面向工程的交付指引

Step 0: Discovery

步骤0：需求探索

Resolve:
  • target users
  • product goal
  • device and usage context
  • existing design-system or product constraints
  • accessibility expectations
If the problem statement is underspecified, ask before designing.
Success criteria: The design problem is framed in user and product terms, not just screens.
明确以下内容：
  • 目标用户
  • 产品目标
  • 设备与使用场景
  • 现有设计系统或产品约束
  • 无障碍要求
如果问题描述不够明确，先询问用户再开展设计。
成功标准：设计问题从用户和产品角度进行定义，而非仅局限于界面。

Step 1: Model flows and states

步骤1：建模流程与状态

Document:
  • primary user journey
  • edge cases
  • loading, empty, partial, success, and error states
  • key decisions or branching points
Use 
references/user-flow-template.md
when writing flow documentation.
Success criteria: The design covers behavior across states, not just the happy path.
记录：
  • 主要用户旅程
  • 边缘情况
  • 加载、空状态、部分加载、成功和错误状态
  • 关键决策或分支节点
编写流程文档时使用
references/user-flow-template.md
模板。
成功标准：设计覆盖了不同状态下的行为，而非仅包含理想路径。

Step 2: Specify components and interaction rules

步骤2：定义组件与交互规则

For the needed components, define:
  • purpose
  • variants
  • props or data needs
  • states
  • interaction feedback
  • responsive behavior
  • accessibility requirements
Use 
references/component-spec-template.md
for structured component briefs.
Success criteria: The engineering handoff is concrete enough to implement without guessing.
针对所需组件，明确：
  • 用途
  • 变体
  • 属性或数据需求
  • 状态
  • 交互反馈
  • 响应式表现
  • 无障碍要求
使用
references/component-spec-template.md
模板来构建结构化的组件说明。
成功标准：交付给工程的指引足够具体，无需猜测即可实现。

Step 3: Define tokens and system-level decisions

步骤3：定义令牌与系统级决策

Specify only the tokens and conventions the feature actually needs:
  • color roles
  • typography hierarchy
  • spacing and layout rhythm
  • motion and feedback rules
  • semantic states such as success, warning, danger, disabled
Use 
references/design-tokens-template.md
when a token artifact is required.
Success criteria: The spec encodes reusable system decisions, not just one-off styling notes.
仅明确该功能实际需要的令牌与约定：
  • 颜色角色
  • 排版层级
  • 间距与布局节奏
  • 动效与反馈规则
  • 语义状态（如成功、警告、危险、禁用）
当需要令牌相关产物时，使用
references/design-tokens-template.md
模板。
成功标准：规范中包含可复用的系统决策，而非仅一次性的样式说明。

Step 4: Handoff to the right engineering surface

步骤4：交付至合适的工程对接方

Agent Selection

Agent选择

CriteriaTarget Agent
Server-side rendering needed
nextjs-senior-engineer
SEO critical
nextjs-senior-engineer
App Router / Server Components
nextjs-senior-engineer
API routes / Server Actions
nextjs-senior-engineer
Pure SPA / client-only
react-vite-tailwind-engineer
CLI with web UI
react-vite-tailwind-engineer
Electron/Tauri app
react-vite-tailwind-engineer
Static site with no SSREither (ask user)
UnclearAsk user
State:
  • which implementation target and why it fits
  • the acceptance criteria for engineering handoff
Success criteria: Another agent can pick up the design package and implement it directly.
判定标准目标Agent
需要服务端渲染
nextjs-senior-engineer
SEO至关重要
nextjs-senior-engineer
使用App Router / Server Components
nextjs-senior-engineer
API路由 / Server Actions
nextjs-senior-engineer
纯SPA / 仅客户端
react-vite-tailwind-engineer
带Web UI的CLI
react-vite-tailwind-engineer
Electron/Tauri应用
react-vite-tailwind-engineer
无SSR的静态站点两者均可（询问用户）
不明确询问用户
说明：
  • 选择的实现目标及其适配原因
  • 工程交付的验收标准
成功标准：其他Agent可直接接手该设计包并开展实现工作。

Guardrails

约束规则

  • Do not implement production UI code from this skill.
  • Do not skip accessibility, state coverage, or responsive behavior.
  • Do not produce vague design prose when a concrete artifact is needed.
  • Do not ignore existing product patterns unless the user asked for a redesign.
  • 不要通过此技能编写生产环境UI代码。
  • 不要跳过无障碍、状态覆盖或响应式表现的要求。
  • 当需要具体产物时，不要撰写模糊的设计描述。
  • 除非用户要求重设计，否则不要忽略现有产品模式。

When To Load References

何时使用参考模板

  • references/user-flow-template.md
    Use for user journeys and acceptance flow documentation.
  • references/component-spec-template.md
    Use for component briefs and interface contracts.
  • references/design-tokens-template.md
    Use when the task requires tokenized styling decisions or system handoff.
  • references/user-flow-template.md
    用于用户旅程和验收流程文档。
  • references/component-spec-template.md
    用于组件说明和接口约定。
  • references/design-tokens-template.md
    当任务需要令牌化样式决策或系统交付时使用。

Output Contract

输出约定

Report or write:
  1. user and context summary
  2. flows and states
  3. component specs
  4. design tokens or styling rules if needed
  5. handoff target and implementation acceptance criteria
需提交或撰写：
  1. 用户与场景总结
  2. 流程与状态
  3. 组件规范
  4. 设计令牌或样式规则（如有需要）
  5. 交付目标与实现验收标准