Back to Details

i-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

第一阶段：调研访谈

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

第二阶段：设计概要

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. 交互模型 用户如何与该功能交互。点击、hover、滚动时会触发什么效果？用户会得到什么反馈？从进入到完成的流程是什么样的？
7. 内容要求 需要哪些文案、标签、空状态提示、错误提示和微文案。说明所有动态内容及其合理范围。
8. 推荐参考资料 基于本概要，列出实现过程中最有价值的impeccable参考文件（例如复杂布局可参考spatial-design.md，动效功能可参考motion-design.md，表单密集的功能可参考interaction-design.md）。
9. 待确认问题 所有未解决、需要实现者在开发过程中确认的内容。
遇到无法推断的内容直接询问用户确认。结束前必须获得用户对概要的明确确认。如果用户不认可任何部分，回溯对应的调研问题重新确认。
确认完成后，设计概要即生效。用户可以将其交付给/impeccable craft来开发功能，或者用它来指导其他实现方案。