Back to Details

all-in-one-ui-ux-design

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

All-in-One UI/UX Design

一站式UI/UX设计

Use this skill as the default end-to-end UI/UX system. Keep this file focused on workflow. Load reference files only when needed.
Goal: deliver memorable interfaces that are production-ready, accessible, and maintainable.
将此技能作为默认的端到端UI/UX系统使用。保持此文件聚焦于工作流，仅在需要时加载参考文件。
目标：交付可投入生产、具备无障碍性且易于维护的令人印象深刻的界面。

Start Here

开始之前

Collect the minimum context before generating or reviewing code:
  1. Product context: product type, audience, tone, and brand constraints.
  2. Scope: full page/app, component set, redesign, or UI audit.
  3. Platform and stack: web/mobile + framework/library choices.
  4. Required states: loading, empty, error, success, disabled, and edge cases.
  5. Delivery target: prototype, production code, audit findings, or design system spec.
If details are missing, ask 1-3 focused questions. If the user prefers speed, proceed with explicit assumptions.
在生成或评审代码前，收集最少必要的上下文信息：
  1. 产品背景：产品类型、受众、风格调性及品牌约束。
  2. 范围：完整页面/应用、组件集、重新设计或UI审核。
  3. 平台与技术栈：Web/移动端 + 框架/库选择。
  4. 所需状态：加载、空状态、错误、成功、禁用及边缘情况。
  5. 交付目标：原型、生产代码、审核结果或设计系统规范。
若细节缺失，提出1-3个针对性问题。若用户偏好快速推进，则基于明确的假设继续。

Mode Selection

模式选择

Pick the mode that matches intent:
  1. build
    : design and implement new UI.
  2. redesign
    : keep functionality, replace visual and interaction layer.
  3. audit
    : review existing UI and return actionable findings.
  4. design-system
    : define tokens, type scale, and component primitives before coding.
  5. flow
    : design multi-screen journeys (onboarding, checkout, settings, dashboards).
For mixed requests, run 
design-system -> build -> audit
in sequence.
选择与需求匹配的模式：
  1. build
    ：设计并实现新UI。
  2. redesign
    ：保留功能，替换视觉与交互层。
  3. audit
    ：评审现有UI并返回可执行的发现结果。
  4. design-system
    ：在编码前定义设计令牌、字阶及组件基础元素。
  5. flow
    ：设计多界面流程（引导页、结账流程、设置、仪表盘）。
对于混合需求，按
design-system -> build -> audit
的顺序执行。

Default Recommendations

默认推荐

Use these defaults unless the user asks otherwise:
  1. Stack selection: Use the stack already present in the codebase. If no stack is present and the task is web, default to 
    html-tailwind
    . If no stack is present and the task is mobile, use platform-native patterns.
  2. Audit depth: Use full checklist audit by default. Use quick audit only when the user explicitly asks for speed over depth.
  3. Creativity: Do not rely on rigid templates as the primary output. Use a bespoke direction per project, with reusable principles instead of cloned layouts. Use 
    assets/primitives/
    as composable scaffolding, not final visual identity.
除非用户另有要求，否则使用以下默认设置：
  1. 技术栈选择： 使用代码库中已有的技术栈。 若没有指定技术栈且任务为Web端，默认使用
    html-tailwind
    。 若没有指定技术栈且任务为移动端，使用平台原生模式。
  2. 审核深度： 默认使用完整清单审核。 仅当用户明确要求优先速度而非深度时，才使用快速审核。
  3. 创意性： 不要依赖僵化的模板作为主要输出。 为每个项目定制专属的设计方向，采用可复用的原则而非克隆现有布局。 将
    assets/primitives/
    作为可组合的脚手架，而非最终的视觉标识。

Reference Loading Map

参考文件加载映射

Load only what the task needs:
FileLoad when
references/creative-direction.mdChoosing style direction, typography personality, palette mood, layout composition, and visual differentiation
references/system-build-playbook.mdBuilding implementation plans, selecting stacks, applying UX priority rules, and using final delivery checklists
references/web-interface-guidelines.mdAuditing UI code for accessibility, interaction, performance, copy quality, and anti-pattern detection
仅加载任务所需的文件：
文件加载时机
references/creative-direction.md选择风格方向、排版个性、调色板氛围、布局构图及视觉差异化时
references/system-build-playbook.md制定实施计划、选择技术栈、应用UX优先级规则及使用最终交付清单时
references/web-interface-guidelines.md审核UI代码的无障碍性、交互性、性能、文案质量及检测反模式时

Asset Kit

资产工具包

Use these optional assets when implementation speed is needed without sacrificing originality:
AssetUse for
assets/primitives/tokens.cssTypography, color, spacing, radius, elevation, and semantic token scaffold
assets/primitives/motion.cssMotion tokens, entry effects, and reduced-motion-safe behavior
assets/primitives/layout.cssResponsive layout primitives (container, stack, cluster, grid, section, surface)
assets/primitives/component-states.cssAccessible default states for buttons, fields, and cards
assets/blueprints/semantic-shell.htmlMinimal semantic page skeleton for rapid prototyping
Asset rules:
  1. Copy only what is needed.
  2. Retheme tokens before final delivery.
  3. Recompose layouts per project; never ship blueprint defaults unchanged.
当需要提升实施速度且不牺牲原创性时，使用以下可选资产：
资产使用场景
assets/primitives/tokens.css排版、颜色、间距、圆角、阴影层级及语义令牌脚手架
assets/primitives/motion.css动效令牌、入场效果及适配减少动效偏好的行为
assets/primitives/layout.css响应式布局基础元素（容器、堆叠、集群、网格、区块、表面）
assets/primitives/component-states.css按钮、输入框及卡片的无障碍默认状态
assets/blueprints/semantic-shell.html用于快速原型开发的极简语义化页面骨架
资产使用规则：
  1. 仅复制所需的内容。
  2. 在最终交付前重新调整令牌主题。
  3. 根据项目重新组合布局；绝不直接交付未修改的蓝图默认样式。

Core Principles

核心原则

  1. Commit to a clear aesthetic direction. Do not produce generic template-looking UI.
  2. Keep style and interaction consistent across the entire surface.
  3. Prioritize accessibility and usability before decorative polish.
  4. Use motion intentionally; communicate state changes, do not add noise.
  5. Build for responsive behavior and real content from the first pass.
  6. Favor readable, maintainable code and tokenized styling over ad hoc values.
  1. 坚持清晰的美学方向。不要产出看起来像通用模板的UI。
  2. 在整个界面中保持风格与交互的一致性。
  3. 在装饰性优化之前，优先考虑无障碍性与可用性。
  4. 有目的地使用动效；用于传达状态变化，而非添加冗余内容。
  5. 从初始阶段就为响应式行为和真实内容进行构建。
  6. 优先选择可读性强、易于维护的代码及令牌化样式，而非临时值。

Non-Negotiable Quality Bar

不可妥协的质量标准

Apply these rules in every mode:
  1. Typography must feel intentional. Avoid default stacks and repetitive safe choices.
  2. Color must be cohesive. Use design tokens or CSS variables for primary, secondary, accent, and semantic states.
  3. Interactive elements must expose visible hover and keyboard focus states.
  4. Touch targets must be at least 44x44px on touch interfaces.
  5. Respect reduced-motion preference and avoid expensive animation properties.
  6. Provide complete state coverage: normal, hover, focus, active, disabled, loading, empty, error, success.
  7. Prevent layout shifts and clipping with explicit media sizing and robust text overflow handling.
  8. Avoid anti-patterns listed in references/web-interface-guidelines.md.
在所有模式中应用以下规则：
  1. 排版必须具有明确的目的性。避免默认技术栈和重复的保守选择。
  2. 颜色必须具有连贯性。使用设计令牌或CSS变量定义主色、辅助色、强调色及语义状态。
  3. 交互元素必须显示可见的悬停及键盘聚焦状态。
  4. 触摸界面上的触摸目标尺寸至少为44x44px。
  5. 尊重减少动效的偏好，避免使用性能开销大的动画属性。
  6. 提供完整的状态覆盖：正常、悬停、聚焦、激活、禁用、加载、空状态、错误、成功。
  7. 通过明确的媒体尺寸设置及健壮的文本溢出处理，防止布局偏移和内容裁剪。
  8. 避免references/web-interface-guidelines.md中列出的反模式。

Anti-Generic Design Checks (Required)

反通用设计检查（必填）

Before final delivery, fail the output if any of these remain:
  1. Default-looking typography choices with no clear intent.
  2. Generic gradient-heavy or template-first visual direction with weak brand fit.
  3. Boilerplate page composition that could belong to any product with minimal changes.
  4. Decorative motion that does not communicate hierarchy, feedback, or state.
  5. No memorable differentiator in type, layout, interaction, or visual texture.
在最终交付前，若存在以下任何情况，需重新优化输出内容：
  1. 排版选择看起来是默认样式，没有明确的设计意图。
  2. 视觉方向以通用渐变或模板优先，与品牌契合度低。
  3. 页面布局为样板式，只需少量修改即可适用于任何产品。
  4. 装饰性动效未传达层级、反馈或状态变化。
  5. 在排版、布局、交互或视觉质感方面没有令人记忆深刻的差异化设计。

End-to-End Workflow

端到端工作流

1. Understand and Frame

1. 理解与框架搭建

  1. Translate request into problem statement and success criteria.
  2. Extract constraints: brand, compliance, performance, deadlines.
  3. Define deliverables and acceptance criteria before coding.
  1. 将需求转化为问题陈述及成功标准。
  2. 提取约束条件：品牌、合规性、性能、截止日期。
  3. 在编码前定义交付物及验收标准。

2. Choose a Design Direction

2. 选择设计方向

  1. Pick one primary visual direction and one secondary supporting influence.
  2. Define mood words, contrast level, texture strategy, and motion character.
  3. Lock direction with a concise design brief before component implementation.
Use references/creative-direction.md for direction options and anti-generic guardrails.
  1. 选择一个主视觉方向和一个辅助视觉风格。
  2. 定义氛围关键词、对比度等级、纹理策略及动效特征。
  3. 在组件实现前，通过简洁的设计简报锁定方向。
使用references/creative-direction.md获取方向选项及反通用设计的约束规则。

3. Define the Design System

3. 定义设计系统

Create a compact spec:
  1. Color tokens: background, surface, text, muted, border, primary, accent, danger, success.
  2. Typography system: display/headline/body/caption styles and line-height rules.
  3. Spacing and radius scales.
  4. Elevation/shadow system and border treatments.
  5. Motion tokens: durations, easing, and reduced-motion fallbacks.
  6. Component primitives: button, input, select, card, modal, tooltip, toast, table.
Use references/system-build-playbook.md for rule priority and stack-specific guidance.
创建简洁的规范：
  1. 颜色令牌：背景、表面、文本、弱化、边框、主色、强调色、危险色、成功色。
  2. 排版系统：展示型/标题/正文/说明文字样式及行高规则。
  3. 间距与圆角尺度。
  4. 阴影层级系统及边框处理方式。
  5. 动效令牌：时长、缓动函数及适配减少动效的降级方案。
  6. 组件基础元素：按钮、输入框、选择器、卡片、模态框、提示框、通知框、表格。
使用references/system-build-playbook.md获取规则优先级及技术栈专属指导。

4. Build Layout and Interaction Architecture

4. 构建布局与交互架构

  1. Draft responsive structure first (mobile-first breakpoints unless specified otherwise).
  2. Define hierarchy, grouping, and scanning paths.
  3. Assign interaction patterns: navigation, filtering, validation, feedback.
  4. Plan edge states early to avoid late-stage regressions.
  1. 首先起草响应式结构（除非另有指定，否则采用移动端优先的断点设置）。
  2. 定义层级、分组及浏览路径。
  3. 指定交互模式：导航、筛选、验证、反馈。
  4. 提前规划边缘状态，避免后期出现回归问题。

5. Implement by Stack

5. 按技术栈实现

  1. Respect user-selected stack. If unspecified, apply the defaults from the 
    Default Recommendations
    section above.
  2. Keep implementation style-consistent with the design system.
  3. Use semantic HTML and accessible component APIs.
  4. Prefer composable primitives and reusable tokens over one-off classes.
  5. If using the Asset Kit, customize tokens, composition, and interaction details before delivery.
  1. 遵循用户选择的技术栈。若未指定，应用“默认推荐”部分中的默认设置。
  2. 保持实现风格与设计系统一致。
  3. 使用语义化HTML及无障碍组件API。
  4. 优先选择可组合的基础元素及可复用的令牌，而非一次性类。
  5. 若使用资产工具包，在交付前定制令牌、组合方式及交互细节。

6. Audit Before Delivery

6. 交付前审核

Run self-review against references/web-interface-guidelines.md:
  1. Accessibility and semantic correctness.
  2. Focus/keyboard and touch quality.
  3. Responsive behavior and overflow handling.
  4. Motion/performance and hydration safety.
  5. Copy clarity and interaction labels.
根据references/web-interface-guidelines.md进行自我评审：
  1. 无障碍性及语义正确性。
  2. 聚焦/键盘及触摸交互质量。
  3. 响应式行为及溢出处理。
  4. 动效/性能及 hydration 安全性。
  5. 文案清晰度及交互标签。

Audit Mode Output Contract

审核模式输出规范

When request intent is review/audit/check:
  1. Findings first, ordered by severity.
  2. Group by file with 
    file:line
    locations.
  3. Keep each finding terse and actionable.
  4. Mention pass status only when file has no issues.
  5. Include residual risks or missing test coverage.
Default behavior:
  1. Run strict/full audit against the complete guideline set.
  2. Switch to quick audit only when user asks for lightweight review.
Format:
text
undefined
当需求为评审/审核/检查时：
  1. 首先列出发现的问题，按严重程度排序。
  2. 按文件分组，并标注
    file:line
    位置。
  3. 每个问题描述简洁且可执行。
  4. 仅当文件无问题时提及通过状态。
  5. 列出剩余风险或缺失的测试覆盖范围。
默认行为：
  1. 针对完整指南集执行严格/全面审核。
  2. 仅当用户要求轻量评审时，切换为快速审核。
格式：
text
undefined

path/to/file.tsx

path/to/file.tsx

path/to/file.tsx:42 - issue summary path/to/file.tsx:77 - issue summary
path/to/file.tsx:42 - 问题摘要 path/to/file.tsx:77 - 问题摘要

path/to/another.tsx

path/to/another.tsx

pass
undefined
pass
undefined

Build Mode Output Contract

构建模式输出规范

When request intent is implementation:
  1. Provide final code or patch.
  2. Summarize design direction in 2-4 bullets.
  3. Confirm key accessibility and responsive decisions.
  4. List known tradeoffs and follow-up improvements.
当需求为实现时：
  1. 提供最终代码或补丁。
  2. 用2-4个要点总结设计方向。
  3. 确认关键的无障碍及响应式决策。
  4. 列出已知的权衡方案及后续改进点。

Rapid Prompt Pattern

快速提问模板

Use this structure internally when requirements are vague:
  1. "Who is this interface for and what is the core action?"
  2. "What emotional tone should the UI convey?"
  3. "What stack or platform constraints apply?"
  4. "What quality constraints are mandatory (a11y, perf, brand, localization)?"
If user does not answer, continue with assumptions and state them clearly.
当需求模糊时，内部使用以下结构提问：
  1. “此界面面向的用户是谁，核心操作是什么？”
  2. “UI应传递怎样的情感基调？”
  3. “存在哪些技术栈或平台约束？”
  4. “哪些质量约束是强制性的（无障碍、性能、品牌、本地化）？”
若用户未回复，基于假设继续，并明确说明这些假设。

Completion Checklist

完成检查清单

Before final delivery, confirm:
  1. Visual direction is distinctive and coherent.
  2. All critical interactions have hover/focus/active/disabled states.
  3. Accessibility checks pass for labels, semantics, focus, and contrast.
  4. Mobile and desktop layouts are verified.
  5. Performance-sensitive behavior (images, animations, lists) is handled.
  6. Copy and error states are specific and user-actionable.
在最终交付前，确认：
  1. 视觉方向独特且连贯。
  2. 所有关键交互都具备悬停/聚焦/激活/禁用状态。
  3. 标签、语义化、聚焦及对比度的无障碍检查通过。
  4. 移动端及桌面端布局已验证。
  5. 对性能敏感的行为（图片、动画、列表）已妥善处理。
  6. 文案及错误状态具体且对用户可执行。