shape

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

范围：仅限设计规划。此技能不会编写代码，而是为编写优质代码提供所需的思考。

输出：一份可交接给任意实现技能的设计简报。

委派给 grill-me 负责第 1 阶段。简报确认后，推荐一种实现技能；不要调用其他由用户调用的技能。

收集背景信息

开始访谈前，先了解项目背景，确保简报能反映现有情况：

• 设计背景——如果代码库中存在 PRODUCT.md、DESIGN.md、.impeccable.md，或 .github/copilot-instructions.md 中的 ## Design Context 区块，请阅读。若均不存在，则静默跳过。
• 现有系统——阅读已确立的设计系统（CSS / tokens / theme，以及一个有代表性的组件或页面），了解当前采用的规范。优先沿用现有规范；只有在 UX 能因此得到提升时才另辟蹊径。
• 设计定位——判断设计本身是否就是产品（营销、着陆页、作品集 → 优先考虑品牌形象和鲜明风格），还是设计服务于产品（应用、仪表板、工具 → 优先考虑清晰和克制）。这将影响下文的每项方向选择。

第 1 阶段：探索式访谈

本阶段不编写代码，也不做任何设计决策。深入了解这项功能，为之后做出出色的设计决策做好准备。

运行 grill-me 技能。为设计决策树预设以下分支，确保探索范围覆盖这些方面：

• 目的和背景——用途、具体使用者、成功标准、用户心态
• 内容和数据——展示或收集的内容、合理的数据范围、空白 / 错误 / 首次使用 / 高级用户场景，以及动态内容
• 设计目标——最重要的单个用户操作、期望营造的感受、现有产品模式、参考示例
• 范围——保真度、广度、交互性、指定的目标对象，以及不做改动的部分
• 约束——技术、内容、移动端、超出 WCAG AA 要求的无障碍约束
• 反目标——错误的方向，以及设计出错的最大风险

代码库中已有明确答案的问题，不要纳入探索范围。grill-me 会在后续轮次中询问其余问题，并提供推荐答案。

第 2 阶段：设计简报

访谈结束后，将所有内容综合整理为一份结构化设计简报。在完成此技能前，先将简报交给用户确认。

任务明确时使用 3 到 5 个项目符号；对于含糊不清或涉及多个屏幕的任务，使用完整结构。需涵盖范围、合理的数据范围、所需媒体的用途，以及实现者不得自行决定的事项。交接前解决会产生重大影响的未决事项；不要将这些问题留给实现阶段。

简要结构

1. 功能概述（2-3 句话） 说明这是什么、面向谁，以及需要实现什么目标。

2. 用户的主要操作 用户在此处最重要的操作或需要理解的内容。

3. 设计方向 说明整体应给人什么感受、适合采用什么美学方向。参考项目在 .impeccable.md 或 .github/copilot-instructions.md（如存在）中描述的设计背景，并说明此功能应如何体现这一背景。

4. 布局策略 从整体上描述空间布局：哪些内容需要突出、哪些内容居于次要位置，以及信息如何流动。描述视觉层级和节奏，不要写具体的 CSS。

5. 关键状态 列出此功能所需的所有状态：默认、空内容、加载、错误、成功和边缘情况。对于每种状态，说明用户需要看到什么、感受到什么。

6. 交互模型 说明用户如何与此功能交互。点击、悬停、滚动时会发生什么？用户会得到什么反馈？从进入到完成的流程是什么？

7. 内容要求 说明需要哪些文案、标签、空状态提示、错误消息和微文案。注明任何动态内容及其合理范围。

8. 推荐参考资料 根据需求说明，列出实施过程中最有价值的参考文件或文档（例如，复杂布局的空间设计指南、动画功能的动态效果设计指南、表单类功能的交互设计指南）。

9. 未决问题 列出所有尚未解决、会阻碍交接的问题。实施前与用户确认；经确认的需求说明不应默认将设计决策交由他人处理。

---

直接询问用户，以澄清无法推断的内容。在完成前，务必获得用户对需求说明的明确确认。如果用户不同意其中任何部分，请重新审视相关的需求探索问题。

确认后，需求说明即告完成。用户现在可以将其交给任意实施技能或采用任意实施方式。