| name | ui-design |
| description | UI 样式修改协作流程（已有界面的视觉层微调）。触发硬条件：页面已经在代码里跑着，改的只是它的视觉表现——布局、间距、颜色、字号、圆角、组件搭配。通过"读代码 + ASCII 画出现状让用户确认 → 给 2-3 个 ASCII 方案 → 用户选定 → 最小改动 → 微调"的流程，减少沟通偏差、避免浪费 token。产出：只动样式的代码 diff。硬边界：不动业务逻辑、不动数据流、不改交互行为、不顺手重构。不适用于：界面还不存在、要从零探索长什么样（用 design-exploration）、改的是功能或交互逻辑而不只是视觉（用 req-change-workflow）、照着设计图/截图复刻整页（用 design-replica）、给还没实现的需求画线框（用 design-exploration 或 prd-test-writer）。 |
用户要求修改页面的 UI 样式（布局、间距、颜色、组件搭配等视觉层面的调整）。通过结构化的协作流程完成修改，确保每一步都对齐目标，不做无效猜测。
核心原则
- 不猜，不抢跑 — 没有对齐目标之前，绝不动代码
- 截图是第一语言 — 主动要求用户提供截图，用截图定位问题
- ASCII 画方案 — 布局方案用 ASCII 画出来，文字描述容易产生歧义
- 每次只改一个点 — 不要一次改多个地方，逐步逼近目标
工作流程
第 1 步：定位问题
用户说想改某个地方时，先做两件事：
- 读代码 — 读取相关文件，理解当前实现
- 描述现状 — 用 ASCII 画出当前布局，向用户确认："我看到的是这样，对吗？"
示例：
┌─────────────────────────────────────────────┐
│ 📈 标题 [🔄] │
│ 副标题说明文字 │
│ 🔍 [搜索框... ] │
├─────────────────────────────────────────────┤
禁止：跳过这一步直接问"你想改成什么样"。必须先让用户确认你理解了现状。
第 2 步：给出方案
提供 2-3 个方案，每个方案包含：
- ASCII 布局图 — 画出改完的样子
- 一句话说明 — 这个方案的核心思路是什么
示例：
方案 A：搜索和刷新放同一行
┌──────────────────────────────────────────┐
│ 🔍 [搜索框... ] [🔄] │
└──────────────────────────────────────────┘
方案 B：刷新挪到标题行
┌──────────────────────────────────────────┐
│ 📈 标题 [🔄] │
│ 🔍 [搜索框... ] │
└──────────────────────────────────────────┘
禁止：
- 只给一个方案（用户没有选择余地）
- 给超过 3 个方案（选择困难）
- 方案只有文字没有 ASCII 图
第 3 步：等用户选择
用户选完方案后，才开始写代码。
禁止：用户还没选就开始改代码。
第 4 步：改代码
执行最小改动，只改用户选定方案涉及的部分。
禁止：顺手改其他地方、优化代码结构、加注释。
第 5 步：微调
改完后让用户看效果。用户可能会提出微调：
微调是具体的、小的修改，直接执行，不需要再走方案选择流程。
如果用户的反馈不够具体（比如"感觉不对"），主动追问：
- "是大小的问题、颜色的问题、还是位置的问题？"
- "和旁边哪个元素搭配起来不协调？"
沟通规范
用户应该提供的
| 信息 | 说明 |
|---|
| 截图 | 标注出想改的区域 |
| 问题描述 | "这两个元素搭配不协调"、"间距太大" |
| 选择方案 | 从给出的方案中选一个 |
AI 应该做的
| 阶段 | 输出 |
|---|
| 定位 | ASCII 现状图 |
| 方案 | 2-3 个 ASCII 方案图 + 一句话说明 |
| 改码 | 最小改动，只改选定方案 |
| 微调 | 直接执行具体调整 |
AI 绝不应该做的
- 用户说"改布局"就直接猜想法然后改代码
- 一次给出大段代码重构
- 微调阶段还在给多个方案让用户选
- 顺手改用户没提到的地方
