shape

上下文： 此子技能是更广泛的 ui-craft 技能的一种视角。如果也安装了 ui-craft 技能，请先阅读其 SKILL.md，完成探索 + 反套路 + 工艺测试，再应用下面的特定视角。

在编写代码之前，为 $ARGUMENTS 设计 UI 形态。加载 ui-craft 技能。

此命令生成的是形态方案，而非 JSX。目的是强制先进行低保真思考——内容清单、布局区域、状态覆盖范围、待解决问题——再编写任何组件。跳过此步骤，就会构建出千篇一律的 AI UI：直接做高保真设计，没有探索，每个屏幕看起来都一样。

步骤 1 — 澄清（3-5 个问题）。 设计之前先询问用户。不要猜测。至少询问：

• 此屏幕上的主要用户操作是什么？（一个动词、一个对象。）
• 默认可见的数据有哪些？哪些数据隐藏在点击操作或标签页后？
• 成功是什么样的——某种状态、重定向，还是提示消息？
• 主要用户是谁——初次使用者、重度用户，还是移动端优先的用户？

步骤 2 — 内容清单。 用项目符号列出将出现的每项内容，并标注优先级：

• P0 — 首次绘制时必须可见。删掉它，屏幕就无法发挥作用。
• P1 — 一次点击即可查看（标签页、折叠面板、抽屉）。
• P2 — 设置级内容；很少访问。

示例：

- P0  Headline (one line, the value prop)
- P0  Primary CTA
- P0  Hero chart / metric
- P1  Secondary nav tabs
- P1  Recent activity list
- P2  Export / integrations menu

步骤 3 — ASCII 布局。 绘制低保真草图，展示各个区域。不写具体文案，不用颜色，不标注字号。提供一个桌面端版本和一个移动端版本。使用方框字符：

Desktop
┌──────────────────────────────────────────────┐
│ [logo]                 [nav]         [user]  │
├──────────────────────────────────────────────┤
│  ┌────────────────┐   ┌───────────────────┐  │
│  │ Headline + sub │   │                   │  │
│  │                │   │   Hero visual     │  │
│  │ [Primary CTA]  │   │                   │  │
│  └────────────────┘   └───────────────────┘  │
│                                              │
│  ── Social proof row ──                      │
│                                              │
│  ┌─── Feature 1 ───┐   ┌─── Feature 2 ───┐   │
│  └─────────────────┘   └─────────────────┘   │
└──────────────────────────────────────────────┘

Mobile
┌──────────────────┐
│ [logo]     [☰]   │
├──────────────────┤
│  Headline + sub  │
│                  │
│  [Primary CTA]   │
│                  │
│  ┌── Hero ──┐    │
│  └──────────┘    │
│                  │
│  Social proof    │
│                  │
│  Feature 1       │
│  Feature 2       │
└──────────────────┘

布局不对称完全没问题，而且往往更好——不要强行让所有内容居中。

步骤 4 — 状态列表。 列出此屏幕必须处理的状态。状态规范见 references/state-design.md。

• idle — 默认状态，数据已就绪。
• loading — 骨架屏应与最终布局一致，显示前延迟 200ms。
• empty — 首次运行或无数据；同时承担引导作用。
• error — 明确具体原因 + 恢复操作 + 支持 ID。
• partial — 部分数据已加载，部分加载失败（例如，一个小组件出错）。
• conflict — 用户编辑冲突（不常见，但对协作界面至关重要）。
• offline — 将写入操作加入队列，重新连接后进行同步。
• success — 主要操作完成后的确认状态。

将每种状态标记为必需 / 可选（说明原因） / 不适用。

步骤 5 — 待解决问题。 在这些问题得到回答之前，不要开始编码。默认问题集：

• 强调色 — 由品牌定义，还是自行选择？（参见 SKILL.md 中的探索部分。）
• 字体排版 — 使用现有设计令牌，还是采用新体系？（参见 typography.md。）
• 响应式断点 — 支持的最小宽度是多少？
• 技术栈 — 仅使用 CSS，还是使用 Motion / GSAP / Three.js？（只有用户选择后才加载 stack.md。）
• 数据来源 — 已有可用的真实 API，还是使用模拟数据来设计形态？
• 键盘 / 无障碍要求 — 除 accessibility.md 中的基线要求外，还有其他要求吗？

旋钮说明。

• 当 CRAFT_LEVEL ≥ 7 时，增加两个部分：
  • 动效形态 — 哪些元素进入、按什么顺序进入、采用什么交错间隔。根据 references/motion.md 中的时长刻度选择。
  • 字体排版层级规划 — 编码前确定展示文字 / 标题 / 正文 / 标签的字号和字重。
• 当 CRAFT_LEVEL ≤ 4 时，将步骤 4 精简为仅包含 idle / loading / error。跳过动效形态。

步骤 6 — 提议将内容保存到 .ui-craft/spec.md（可选）。

打印完全部五个步骤后，询问是否将输出写为规范章节：

“要将此形态方案写入 .ui-craft/spec.md，作为 ## Surface: <name> 吗？（保存构成选择、布局和构建阶段的验收标准。）”

• 用户确认 → 按照 ../skills/ui-craft/references/spec.md 中的模板，将输出整理为 ## Surface: <name> 章节，然后写入或追加到 .ui-craft/spec.md。用一行确认：“已写入 .ui-craft/spec.md → ## Surface: <name>。”
• 用户拒绝 → 不写入任何文件。保留已打印的输出。注明：“未写入 spec.md——流程将继续，但不会保存验收标准。” 单独运行 /shape 时，默认只打印内容。第 6 步是提出选项；只有用户明确确认后才会执行。

输出约定。

• 按顺序生成包含全部五个步骤的单个 Markdown 区块。第 6 步是随后提供的可选选项。
• 此命令中不得编写 JSX、CSS 或组件代码。
• 输出结尾必须为："准备好构建了吗？请检查设计方案，确认未决问题，然后运行 /ui-craft:audit（或使用 Build 模式），前提是代码已存在。"

下一步： /craft — 构建刚才完成线框设计的界面（第 1 级）。