Back to Details

shape

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

MANDATORY PREPARATION

强制准备

Invoke /impeccable, which contains design principles, anti-patterns, and the Context Gathering Protocol. Follow the protocol before proceeding. If no design context exists yet, you MUST run /impeccable teach first.
Shape the UX and UI for a feature before any code is written. This skill produces a design brief: a structured artifact that guides implementation through discovery, not guesswork.
Scope: Design planning only. This skill does NOT write code. It produces the thinking that makes code good.
Output: A design brief that can be handed off to /impeccable craft, /impeccable, or any other implementation skill.
调用/impeccable，该工具包含设计原则、反模式以及上下文收集协议。在继续操作前请遵循该协议。如果尚无设计上下文，你必须先运行/impeccable teach命令。
在编写任何代码前梳理功能的UX和UI。本技能会生成设计概要：这是一份结构化的产出物，可通过需求发掘而非主观猜测来指导落地实现。
适用范围：仅用于设计规划。本技能不会编写代码，它的产出是保障代码质量的前置思考。
输出：可交付给/impeccable craft、/impeccable或其他任何实现类技能使用的设计概要。

Philosophy

设计理念

Most AI-generated UIs fail not because of bad code, but because of skipped thinking. They jump to "here's a card grid" without asking "what is the user trying to accomplish?" This skill inverts that: understand deeply first, so implementation is precise.
大多数AI生成的UI之所以失败，并非因为代码质量差，而是因为省略了思考过程。它们没有先问「用户想要达成什么目标」，就直接给出「这里放个卡片网格」的方案。本技能扭转了这一逻辑：先深度理解需求，再精准落地实现。

Phase 1: Discovery Interview

阶段1：需求发掘访谈

Do NOT write any code or make any design decisions during this phase. Your only job is to understand the feature deeply enough to make excellent design decisions later.
Ask these questions in conversation, adapting based on answers. Don't dump them all at once; have a natural dialogue. ask the user directly to clarify what you cannot infer.
在此阶段不要编写任何代码，也不要做出任何设计决策。 你唯一的工作是足够深入地理解功能，以便后续做出优质的设计决策。
在对话中询问以下问题，并根据用户的回答灵活调整。不要一次性抛出所有问题，要开展自然的对话。对于无法推断的内容，直接询问用户予以明确。

Purpose & Context

目标与上下文

  • What is this feature for? What problem does it solve?
  • Who specifically will use it? (Not "users"; be specific: role, context, frequency)
  • What does success look like? How will you know this feature is working?
  • What's the user's state of mind when they reach this feature? (Rushed? Exploring? Anxious? Focused?)
  • 这个功能的用途是什么？它解决了什么问题？
  • 具体的使用人群是谁？（不要泛泛回答「用户」，请给出具体信息：角色、使用场景、使用频率）
  • 成功的标准是什么？如何判断这个功能达到了预期效果？
  • 用户使用这个功能时的心理状态是什么样的？（匆忙？探索？焦虑？专注？）

Content & Data

内容与数据

  • What content or data does this feature display or collect?
  • What are the realistic ranges? (Minimum, typical, maximum, e.g., 0 items, 5 items, 500 items)
  • What are the edge cases? (Empty state, error state, first-time use, power user)
  • Is any content dynamic? What changes and how often?
  • 这个功能需要展示或收集什么内容或数据？
  • 内容/数据的合理范围是多少？（最小值、典型值、最大值，例如0项、5项、500项）
  • 有哪些边缘场景？（空状态、错误状态、首次使用、高阶用户场景）
  • 是否存在动态内容？什么内容会变化、更新频率是多少？

Design Goals

设计目标

  • What's the single most important thing a user should do or understand here?
  • What should this feel like? (Fast/efficient? Calm/trustworthy? Fun/playful? Premium/refined?)
  • Are there existing patterns in the product this should be consistent with?
  • Are there specific examples (inside or outside the product) that capture what you're going for?
  • 用户在此页面最需要完成的操作或理解的信息是什么？
  • 功能的整体感受应该是什么样的？（快捷高效？平静可信？轻松有趣？高端精致？）
  • 产品中有没有需要保持一致性的现有设计规范？
  • 是否有具体的参考案例（产品内或产品外）符合你想要的效果？

Constraints

约束条件

  • Are there technical constraints? (Framework, performance budget, browser support)
  • Are there content constraints? (Localization, dynamic text length, user-generated content)
  • Mobile/responsive requirements?
  • Accessibility requirements beyond WCAG AA?
  • 是否有技术约束？（框架、性能预算、浏览器支持要求）
  • 是否有内容约束？（本地化、动态文本长度、用户生成内容）
  • 移动端/响应式适配要求？
  • 是否有超出WCAG AA的无障碍要求？

Anti-Goals

反目标

  • What should this NOT be? What would be a wrong direction?
  • What's the biggest risk of getting this wrong?
  • 这个功能不应该做成什么样？什么方向是错误的？
  • 设计出错的最大风险是什么？

Phase 2: Design Brief

阶段2：设计概要

After the interview, synthesize everything into a structured design brief. Present it to the user for confirmation before considering this skill complete.
访谈结束后，将所有信息整合为结构化的设计概要。在本技能执行完成前，需要将概要提交给用户确认。

Brief Structure

概要结构

1. Feature Summary (2-3 sentences) What this is, who it's for, what it needs to accomplish.
2. Primary User Action The single most important thing a user should do or understand here.
3. Design Direction How this should feel. What aesthetic approach fits. Reference the project's design context from 
.impeccable.md
and explain how this feature should express it.
4. Layout Strategy High-level spatial approach: what gets emphasis, what's secondary, how information flows. Describe the visual hierarchy and rhythm, not specific CSS.
5. Key States List every state the feature needs: default, empty, loading, error, success, edge cases. For each, note what the user needs to see and feel.
6. Interaction Model How users interact with this feature. What happens on click, hover, scroll? What feedback do they get? What's the flow from entry to completion?
7. Content Requirements What copy, labels, empty state messages, error messages, and microcopy are needed. Note any dynamic content and its realistic ranges.
8. Recommended References Based on the brief, list which impeccable reference files would be most valuable during implementation (e.g., spatial-design.md for complex layouts, motion-design.md for animated features, interaction-design.md for form-heavy features).
9. Open Questions Anything unresolved that the implementer should resolve during build.
ask the user directly to clarify what you cannot infer. Get explicit confirmation of the brief before finishing. If the user disagrees with any part, revisit the relevant discovery questions.
Once confirmed, the brief is complete. The user can now hand it to /impeccable craft to build the feature, or use it to guide any other implementation approach.
1. 功能概述（2-3句话） 说明功能是什么、面向谁、需要达成什么目标。
2. 核心用户行为 用户在此页面最需要完成的操作或理解的信息。
3. 设计方向 功能的整体感受，适配的美学风格。参考
.impeccable.md
中的项目设计上下文，说明该功能应该如何体现设计规范。
4. 布局策略 高层级的空间排布逻辑：哪些内容需要突出、哪些是次要信息、信息的流转逻辑。只描述视觉层级和节奏，不要涉及具体的CSS实现。
5. 核心状态 列出功能需要覆盖的所有状态：默认、空、加载中、错误、成功、边缘场景。针对每个状态，说明用户需要看到的内容和感知到的反馈。
6. 交互模型 用户如何与该功能交互。点击、悬停、滚动时会触发什么操作？用户会得到什么反馈？从进入功能到完成操作的完整流程是什么样的？
7. 内容要求 需要哪些文案、标签、空状态提示、错误提示、微文案。标注所有动态内容及其合理范围。
8. 推荐参考资料 基于设计概要，列出实现阶段最有价值的impeccable参考文件（例如复杂布局可参考spatial-design.md，动效功能可参考motion-design.md，多表单功能可参考interaction-design.md）。
9. 待解决问题 所有未明确、需要实现者在开发过程中确认的内容。
对于无法推断的内容，直接询问用户予以明确。完成前需要获得用户对设计概要的明确确认。如果用户不认可任何部分，回到对应的需求发掘环节重新调研。
确认通过后，设计概要即完成。用户可以将其交付给/impeccable craft来开发功能，也可以用它来指导其他实现方案。