shape

强制准备

调用 /impeccable，其中包含设计原则、反模式和上下文收集协议。继续之前，请遵循该协议。如果目前还没有设计上下文，则必须先运行 /impeccable teach。

---

在编写任何代码之前，为某项功能规划 UX 和 UI。此技能会产出一份设计简报：一种结构化成果，通过探索而非猜测来指导实现。

范围：仅限设计规划。此技能不会编写代码。它会产出让代码更出色的思考成果。

输出：一份设计简报，可交接给 /impeccable craft、/impeccable 或任何其他实现技能。

理念

大多数 AI 生成的 UI 失败，并非因为代码不好，而是因为跳过了思考过程。它们会直接给出“卡片网格”，却不问“用户想要完成什么？”此技能将这一顺序颠倒：先深入理解，才能精准实现。

阶段 1：探索访谈

此阶段不得编写任何代码，也不得做出任何设计决策。 你唯一的任务是深入理解这项功能，以便之后做出出色的设计决策。

在对话中提出以下问题，并根据回答灵活调整。不要一次性抛出所有问题；应进行自然的对话。对于无法推断的信息，直接向用户询问并澄清。

目的与背景

• 这项功能有什么用途？它解决什么问题？
• 具体哪些人会使用它？（不要只说“用户”；请说明角色、使用场景和频率）
• 怎样才算成功？你如何判断这项功能正常发挥作用？
• 用户使用这项功能时是什么心态？（赶时间？正在探索？焦虑？专注？）

内容与数据

• 这项功能会展示或收集哪些内容或数据？
• 实际的数据范围是什么？（最少、典型、最多，例如：0 项、5 项、500 项）
• 有哪些边缘情况？（空状态、错误状态、首次使用、熟练用户）
• 是否有动态内容？哪些内容会变化，变化频率如何？

设计目标

• 用户在此最重要的操作或理解是什么？
• 希望呈现怎样的感觉？（快速高效？平静可信？有趣活泼？高端精致？）
• 产品中是否已有需要保持一致的设计模式？
• 有没有具体示例（产品内或产品外），能够体现你想要的设计方向？

约束

• 有哪些技术约束？（框架、性能预算、浏览器支持）
• 有哪些内容约束？（本地化、动态文本长度、用户生成内容）
• 对移动端或响应式布局有什么要求？
• 除 WCAG AA 外，还有哪些无障碍要求？

反目标

• 哪些方向不应该采用？什么样的设计方向是错误的？
• 如果设计错了，最大的风险是什么？

阶段 2：设计简报

访谈结束后，将所有内容整理成一份结构化的设计简报。请先提交给用户确认，再视为此技能完成。

简要结构

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，或用它指导其他实现方式。（如果用户希望一步完成完整的需求发现和构建流程，应改用 /impeccable craft，该命令会在内部运行此技能。）