design-lab

设计实验室技能

此技能实现完整的设计探索工作流：访谈、生成变体、收集反馈、优化、预览并定稿。

重要：清理行为

流程结束时必须删除所有临时文件，无论是以下哪种情况：

• 用户确认最终设计 → 清理，然后生成计划
• 用户中止/取消 → 立即清理，不生成计划

绝不能遗留 .claude-design/ 或 __design_lab 路由。 如果用户在任何时候说“取消”“中止”“停止”或“算了”，请先确认，然后删除所有临时文件。

---

阶段 0：预检检测

开始访谈前，自动检测：

包管理器

检查项目根目录中的锁文件：

• pnpm-lock.yaml → 使用 pnpm
• yarn.lock → 使用 yarn
• package-lock.json → 使用 npm
• bun.lockb → 使用 bun

框架检测

检查配置文件：

• next.config.js 或 next.config.mjs 或 next.config.ts → Next.js
  • 检查是否有 app/ 目录 → App Router
  • 检查是否有 pages/ 目录 → Pages Router
• vite.config.js 或 vite.config.ts → Vite
• remix.config.js → Remix
• nuxt.config.js 或 nuxt.config.ts → Nuxt
• astro.config.mjs → Astro

样式系统检测

检查 package.json 依赖项和配置文件：

• tailwind.config.js 或 tailwind.config.ts → Tailwind CSS
• 依赖项中包含 @mui/material → Material UI
• 依赖项中包含 @chakra-ui/react → Chakra UI
• 依赖项中包含 antd → Ant Design
• 依赖项中包含 styled-components → styled-components
• 依赖项中包含 @emotion/react → Emotion
• .css 或 .module.css 文件 → CSS Modules

设计记忆检查

查找现有的设计记忆文件：

• docs/design-memory.md
• DESIGN_MEMORY.md
• .claude-design/design-memory.md

如果找到，请阅读并用其预填默认值，跳过重复提问。

视觉风格推断（重要）

不要使用通用/预定义风格。请从项目中提取视觉语言：

如果检测到 Tailwind，读取 tailwind.config.js 或 tailwind.config.ts：

// Extract and use:
theme.colors      // Color palette
theme.spacing     // Spacing scale
theme.borderRadius // Radius values
theme.fontFamily  // Typography
theme.boxShadow   // Elevation system

如果存在 CSS 变量，读取 globals.css、variables.css 或 :root 定义：

:root {
  --color-*     /* Color tokens */
  --spacing-*   /* Spacing tokens */
  --font-*      /* Typography tokens */
  --radius-*    /* Border radius tokens */
}

如果检测到 UI 库（MUI、Chakra、Ant），读取主题配置：

• MUI：theme.ts 或 createTheme() 调用
• Chakra：theme/index.ts 或 extendTheme() 调用
• Ant：ConfigProvider 的 theme 属性

始终扫描现有组件，以了解项目模式：

• 查找 2-3 个现有按钮 → 记录其样式模式
• 查找 2-3 个现有卡片 → 记录内边距、边框和阴影
• 查找现有表单 → 记录输入框样式和标签位置
• 查找现有排版样式 → 记录标题字号和正文文本样式

将推断出的样式存入设计简报，以便在所有变体中保持一致。

---

阶段 1：访谈

所有访谈步骤都使用 AskUserQuestion 工具。若存在设计记忆，请据此调整问题。

步骤 1.1：范围与目标

提出以下问题（可通过一次包含多个问题的 AskUserQuestion 提出）：

问题 1：范围

• 标题：“范围”
• 问题：“我们要设计单个组件还是完整页面？”
• 选项：
  • “组件” - 可复用的 UI 元素（按钮、卡片、表单、模态框等）
  • “页面” - 完整的页面或屏幕布局

问题 2：全新设计还是重新设计

• 标题：“类型”
• 问题：“这是全新设计，还是对现有内容进行重新设计？”
• 选项：
  • “全新设计” - 从头开始创建
  • “重新设计” - 改进现有组件/页面

如果选择“重新设计”，请询问： 问题 3：现有路径

• 标题：“位置”
• 问题：“现有 UI 的文件路径或路由是什么？”
• 选项：（让用户通过“其他”提供）

如果目标不明确，请根据仓库模式提出一个名称并确认。

步骤 1.2：痛点与灵感

问题 1：痛点

• 标题："问题"
• 问题："当前设计最主要的痛点是什么（或者说，这个新设计应避免什么）？"
• 选项：
  • "过于杂乱/密集" - 信息过载，难以浏览
  • "层级不清晰" - 主要操作不够明显
  • "移动端体验差" - 在小屏幕上使用不佳
  • "外观过时" - 感觉老旧，或与品牌风格不一致
• multiSelect: true

问题 2：视觉灵感

• 标题："视觉风格"
• 问题："有哪些产品或品牌可以作为视觉灵感参考？"
• 选项：
  • "Stripe" - 简洁、极简、值得信赖
  • "Linear" - 信息密集、键盘优先、面向开发者
  • "Notion" - 灵活、以内容为中心、活泼
  • "Apple" - 高端、宽敞、精致
• multiSelect: true

问题 3：功能灵感

• 标题："交互"
• 问题："应模仿哪些交互模式？"
• 选项：
  • "行内编辑" - 无需模态框即可就地编辑
  • "渐进式披露" - 按需展示更多内容
  • "乐观更新" - 即时反馈，在后台同步
  • "键盘快捷键" - 提升高级用户的效率

步骤 1.3：品牌与风格方向

问题 1：品牌形容词

• 标题："品牌调性"
• 问题："用 3-5 个形容词描述期望的品牌感觉？"
• 选项：
  • "极简" - 简洁、清爽、不杂乱
  • "高端" - 品质上乘、精致、优雅
  • "活泼" - 有趣、友好、平易近人
  • "实用" - 注重功能、高效、务实
• multiSelect: true

问题 2：信息密度

• 标题："信息密度"
• 问题："你偏好哪种信息密度？"
• 选项：
  • "紧凑" - 显示更多信息，间距更小
  • "舒适" - 间距均衡，便于浏览
  • "宽敞" - 留白充足，注意力更集中

问题 3：深色模式

• 标题："深色模式"
• 问题："是否需要深色模式？"
• 选项：
  • "是" - 必须支持深色模式
  • "否" - 仅支持浅色模式
  • "最好有" - 如果实现容易则支持，但不是必需

步骤 1.4：用户画像与待完成任务

问题 1：主要用户

• 标题："用户"
• 问题："主要终端用户是谁？"
• 选项：
  • "开发者" - 技术能力强、偏好使用键盘
  • "设计师" - 注重视觉、关注细节
  • "业务用户" - 注重效率、技术能力较弱
  • "终端消费者" - 普通大众，技术能力各不相同

问题 2：使用场景

• 标题："场景"
• 问题："主要使用场景是什么？"
• 选项：
  • "桌面端优先" - 主要在较大屏幕上使用
  • "移动端优先" - 主要在手机上使用
  • "两者同等重要" - 必须在所有设备上都能良好运行

问题 3：关键任务

• 标题："关键任务"
• 问题："用户必须完成的 3 项主要任务是什么？"
• （让用户通过“其他”填写——这是开放式问题）

步骤 1.5：约束条件

问题 1：必须保留的元素

• 标题："保留"
• 问题："是否有必须保留的元素？"
• 选项：
  • "现有文案/标签" - 保留当前文本
  • "当前字段/输入项" - 保留表单结构
  • "导航结构" - 保留当前导航
  • "无" - 可以自由更改所有内容

问题 2：技术约束

• 标题："约束条件"
• 问题："是否有任何技术约束？"
• 选项：
  • "不添加新依赖" - 仅使用现有库
  • "使用现有组件" - 基于当前设计系统构建
  • "必须满足无障碍访问要求（WCAG）" - 严格的无障碍访问要求
  • "无" - 没有特殊约束
• multiSelect: true

---

阶段 2：生成设计简报

访谈结束后，将结构化的设计简报生成为 JSON，并保存到 .claude-design/design-brief.json：

{
  "scope": "component|page",
  "isRedesign": true|false,
  "targetPath": "src/components/Example.tsx",
  "targetName": "Example",
  "painPoints": ["Too dense", "Primary action unclear"],
  "inspiration": {
    "visual": ["Stripe", "Linear"],
    "functional": ["Inline validation"]
  },
  "brand": {
    "adjectives": ["minimal", "trustworthy"],
    "density": "comfortable",
    "darkMode": true
  },
  "persona": {
    "primary": "Developer",
    "context": "desktop-first",
    "keyTasks": ["Complete checkout", "Review order", "Apply discount"]
  },
  "constraints": {
    "mustKeep": ["existing fields"],
    "technical": ["no new dependencies", "WCAG accessible"]
  },
  "framework": "nextjs-app",
  "packageManager": "pnpm",
  "stylingSystem": "tailwind"
}

继续之前，先向用户展示摘要。

---

阶段 3：生成设计实验室

目录结构

在 .claude-design/ 下创建所有文件：

.claude-design/
├── lab/
│   ├── page.tsx                 # Main lab page (framework-specific)
│   ├── variants/
│   │   ├── VariantA.tsx
│   │   ├── VariantB.tsx
│   │   ├── VariantC.tsx
│   │   ├── VariantD.tsx
│   │   └── VariantE.tsx
│   ├── components/
│   │   └── LabShell.tsx         # Lab layout wrapper
│   ├── feedback/                # Interactive feedback system
│   │   ├── types.ts             # TypeScript interfaces
│   │   ├── selector-utils.ts    # Element identification
│   │   ├── format-utils.ts      # Feedback formatting
│   │   ├── FeedbackOverlay.tsx  # Main overlay component
│   │   └── index.ts             # Module exports
│   └── data/
│       └── fixtures.ts          # Shared mock data
├── design-brief.json
└── run-log.md

反馈系统设置（至关重要 — 绝不能跳过）

**FeedbackOverlay 是 Design Lab 的核心功能。**没有它，用户就无法提供交互式反馈。绝不能在生成 Design Lab 时省略 FeedbackOverlay。

**可靠性策略：**为避免不同项目配置下出现导入路径问题，请将 FeedbackOverlay 直接放在路由目录中（例如 app/design-lab/FeedbackOverlay.tsx），而不是放在 .claude-design/ 中。这样可以确保简单的相对导入（./FeedbackOverlay）始终有效。

路由目录中的必需文件：

app/design-lab/           # or app/__design_lab/ if underscores work
├── page.tsx              # Main lab page with variants
└── FeedbackOverlay.tsx   # Self-contained overlay component (copy from templates)

模板来源：design-and-refine/templates/feedback/FeedbackOverlay.tsx

采用这种方式的原因：

• .claude-design/ 路径可能因打包器配置而失效
• 从同一目录进行相对导入始终有效
• 清理过程中无论如何都会删除路由目录

路由集成

Next.js App Router： 创建 app/__design_lab/page.tsx，从 .claude-design/lab/ 导入

Next.js Pages Router： 创建 pages/__design_lab.tsx，从 .claude-design/lab/ 导入

Vite React：

• 如果存在 React Router：将路由添加到 /__design_lab
• 如果没有路由器：在 App.tsx 中根据 ?design_lab=true 查询参数进行条件渲染

其他框架： 为检测到的框架创建最合适的临时路由。

变体生成指南

重要：阅读 DESIGN_PRINCIPLES.md，了解 UX、交互和动效最佳实践。但不要使用预定义的视觉样式——应从项目中推断样式。

应用通用原则（来自 DESIGN_PRINCIPLES.md）：

• UX：Nielsen 可用性启发式、降低认知负荷、渐进式呈现
• 组件行为：按钮状态、表单结构、卡片结构
• 交互：反馈模式、状态处理、乐观更新
• 动效：时长（150-300ms）、缓动（进入时 ease-out，退出时 ease-in）
• 无障碍性：焦点状态、ARIA 模式、触控目标（最小 44px）

从项目中推断视觉样式：

• 颜色 → 来自 Tailwind 配置、CSS 变量或现有组件
• 字体排印 → 来自代码库中现有的标题、正文文本
• 间距 → 来自项目的间距比例或现有模式
• 圆角 → 来自现有的卡片、按钮、输入框
• 阴影 → 来自现有的悬浮组件

---

每个变体都必须探索不同的设计方向。不要创建细微的变化——要做出有明显差异的变体。所有变体都应采用项目现有的视觉语言。

变体 A：聚焦信息层级

• 重构内容层级（最重要的是什么？）
• 运用格式塔邻近原则——让相关项彼此靠近
• 每个视图只设置一个主要操作
• 使用现有的字体排印比例来创建清晰的层级

变体 B：探索布局模式

• 尝试不同的布局方式（卡片、列表、表格或分栏面板）
• 应用 DESIGN_PRINCIPLES 中的卡片结构或表格行为模式
• 考虑各断点下的响应式行为
• 使用项目现有的网格／布局系统

变体 C：密度变化

• 如果需求说明写着“宽松”，尝试更紧凑的版本
• 如果需求说明写着“紧凑”，尝试更宽松的版本
• 使用项目现有的间距令牌——只需采用不同的应用方式
• 展示其中的权衡：显示更多数据，还是更易于浏览

变体 D：交互模式

• 使用不同的交互模式（模态框、行内、面板或抽屉）
• 应用反馈模式：即时 → 进行中 → 完成
• 实现所有必需状态（加载、错误、空状态、禁用）
• 考虑为非破坏性操作进行乐观更新

变体 E：表现方向

• 强化用户在访谈中描述的品牌方向
• 探索项目现有设计令牌的不同用法
• 增加或减少阴影、边框、背景色的使用
• 在有助于表达含义的地方应用动效（悬停、焦点、过渡）

设计实验室页面要求

设计实验室页面必须包含：

1. 页眉，包含：

   • 设计简述摘要（目标、范围、关键要求）
   • 审阅说明

2. 变体网格，包含：

   • 清晰的标签（A、B、C、D、E）
   • 每个变体的简要理由（“存在的原因”）
   • 实际渲染的变体
   • 突出关键差异的备注
   • 重要： 每个变体容器必须有 data-variant="X" 属性（其中 X 为 A、B、C、D、E 或 F）。反馈系统需要此属性来识别评论属于哪个变体。

3. 响应式行为：

   • 桌面端：并排网格（2-3 列）
   • 移动端：水平滚动或标签页

4. 共享数据：

   • 所有变体都使用来自 data/fixtures.ts 的同一份固定数据
   • 确保比较公平

5. 反馈覆盖层（至关重要——绝不能省略）：

   ⚠️ 这是最重要的要求 ⚠️

   FeedbackOverlay 让用户能够点击元素并留下评论。没有它，设计实验室就只是一个无法收集结构化反馈的静态页面。

   • 在与 page.tsx 相同的目录中创建 FeedbackOverlay.tsx
   • 使用相对路径导入：import { FeedbackOverlay } from './FeedbackOverlay'
   • 在页面末尾、所有变体之后渲染
   • 传入 targetName 属性，值为组件/页面名称

   集成示例：

import { FeedbackOverlay } from './FeedbackOverlay';  // Relative import - always works

export default function DesignLabPage() {
  return (
    <div className="min-h-screen bg-background">
      <header>...</header>

      <main>
        <div className="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-8">
          <div data-variant="A">
            <VariantA />
          </div>
          <div data-variant="B">
            <VariantB />
          </div>
          {/* ... more variants */}
        </div>
      </main>

      {/* CRITICAL: FeedbackOverlay must be included */}
      <FeedbackOverlay targetName="ComponentName" />
    </div>
  );
}

如果忘记添加 FeedbackOverlay，用户就无法提供反馈。 这会让设计实验室失去全部意义。

代码质量

规范：

• 遵循项目现有的代码规范（文件命名、导入等）
• 使用检测到的样式系统（Tailwind、CSS modules 等）
• 适当使用项目中的现有组件

可访问性（来自 DESIGN_PRINCIPLES）：

• 语义化 HTML：使用 <button> 而不是 <div onclick>，以及 <nav>、<main>、<section>
• 键盘导航：所有交互元素都可聚焦且可操作
• 焦点状态：显示 :focus-visible，带有 2px 的环形轮廓和偏移
• 颜色对比度：文本为 4.5:1，UI 元素为 3:1
• 触控目标：最小尺寸为 44x44px
• 仅在 HTML 语义不足时使用 ARIA

状态（每个组件都需要）：

• 默认、悬停、焦点、激活、禁用、加载、错误、空状态
• 参见 DESIGN_PRINCIPLES 中的“State Handling”部分

动效：

• 使用合适的时间：微交互为 150-200ms，过渡为 200-300ms
• 进入时使用 ease-out，退出时使用 ease-in
• 尊重 prefers-reduced-motion

---

阶段 4：向用户展示设计实验室

生成实验室文件后，立即向用户展示实验室。不要尝试：

• 自行启动开发服务器（它会一直运行并阻塞进程）
• 检查端口是否开放
• 打开浏览器
• 等待服务器响应

操作步骤

1. 输出实验室位置和 URL：

   ✅ Design Lab created!
   
   I've generated 5 design variants in `.claude-design/lab/`
   
   To view them:
   1. Make sure your dev server is running (run `pnpm dev` if not)
   2. Open: http://localhost:3000/__design_lab
   
   Take your time reviewing the variants side-by-side, then come back and tell me:
   - Which variant wins (A-E)
   - What you like about it
   - What should change
   

2. 立即进入阶段 5——征求反馈。不要等待用户说已打开浏览器。直接展示反馈问题，让用户返回时可以立即作答。

不要启动服务器的原因

运行 pnpm dev 或 npm run dev 会启动一个不会退出的长时间运行进程。如果运行它，你会一直等待。用户很可能已经启动了开发服务器，也可以自行在另一个终端中启动。

---

阶段 5：收集反馈

展示实验室 URL 后，用户可以通过两种方式提供反馈：

1. 交互式反馈（推荐）：在浏览器中使用内置覆盖层
2. 手动反馈：通过终端中的 AskUserQuestion

交互式反馈（主要方式）

Design Lab 包含一个类似 Figma 的反馈浮层。展示实验室时，请附上以下说明：

✅ Design Lab created!

I've generated 5 design variants in `.claude-design/lab/`

To view and provide feedback:
1. Make sure your dev server is running (run `pnpm dev` if not)
2. Open: http://localhost:3000/__design_lab

**To add feedback:**
1. Click the "Add Feedback" button (bottom-right corner)
2. Click any element you want to comment on
3. Type your feedback and click "Save"
4. Repeat for all elements you want to comment on
5. Fill in the "Overall Direction" field (required)
6. Click "Submit All Feedback"
7. Paste the copied text here in the terminal

Or just describe your feedback manually below!

用户粘贴反馈时，内容将采用以下格式：

## Design Lab Feedback

**Target:** ComponentName
**Comments:** 3

### Variant A
1. **Button** (`[data-testid='submit']`, button with "Submit")
   "Make this more prominent"

### Variant B
1. **Card** (`.product-card`, div with "Product Name")
   "Love this layout"

### Overall Direction
Go with Variant B's structure. Apply Variant A's button styling.

如何解析并处理这些反馈：

1. 先阅读整体方向——这将指导你的综合判断
2. 针对每条评论，使用以下方式定位元素：
   • 主要方式：反引号中的 CSS 选择器（例如，[data-testid='submit']）
   • 次要方式：元素描述（例如，“带有‘Submit’字样的按钮”）
3. 应用反馈，编辑相应的变体文件

备用方案：通过 AskUserQuestion 手动收集反馈

如果用户不想使用交互式浮层（或粘贴了手动反馈），请使用以下 AskUserQuestion 流程：

阶段 1：确认是否有首选方案

问题 1：准备好选了吗？

• 标题：“决定”
• 问题：“有哪个变体是你喜欢且无需修改的吗？”
• 选项：
  • “有——我找到喜欢的了”——准备选出胜出方案并进行优化
  • “没有——我喜欢不同方案中的一些部分”——需要综合生成一个新变体

阶段 2A：如果用户找到胜出方案

如果用户回答“有”，请询问：

问题 2a：是哪一个？

• 标题：“胜出方案”
• 问题：“你想选哪个变体？”
• 选项：
  • “变体 A”——[A 的简要描述]
  • “变体 B”——[B 的简要描述]
  • “变体 C”——[C 的简要描述]
  • “变体 D”——[D 的简要描述]
  • “变体 E”——[E 的简要描述]

问题 3a：需要调整吗？

• 标题：“调整”
• 问题：“需要做一些小改动，还是现在这样就很好？”
• 选项：
  • “现在这样就很好”——无需修改，继续进行最终预览
  • “需要小幅调整”——我会描述要调整的内容

如果用户选择“需要小幅调整”，请让用户通过文本输入描述改动。

然后继续进入 阶段 7：最终预览。

阶段 2B：如果用户想要综合生成新方案

如果用户回答“没有——我喜欢不同方案中的一些部分”，请询问：

问题 2b：你喜欢每个方案的哪些部分？

• 标题：“反馈”
• 问题：“你喜欢每个变体的哪些部分？（请指出 A、B、C、D、E 中的具体元素）”
• （让用户通过“其他”文本输入提供详细反馈）

可用以下示例回复格式引导用户：

- A: Love the card layout and spacing
- B: The color scheme feels right
- C: The interaction on hover is great
- D: Nothing stands out
- E: The typography hierarchy is clearest

然后继续进入 阶段 6：综合生成新变体。

---

阶段 6：综合生成新变体

根据用户对各个变体中所喜欢内容的反馈：

1. 创建一个新的混合变体（变体 F），综合：

   • 用户指出的各个变体中的具体元素
   • 所有变体中最好的结构设计
   • 在多个变体中反复出现的模式

2. 将 Design Lab 替换为对比视图：

   • 突出展示新综合生成的变体 F
   • 保留 1-2 个最接近的原始变体用于对比
   • 移除用户不喜欢其任何内容的变体

3. 更新 /__design_lab 路由，展示新的布局

4. 再次征求反馈：

问题：新变体怎么样？

• 标题：“评审”
• 问题：“你觉得综合生成的变体（F）怎么样？”
• 选项：
  • “就是这个！”——继续进行最终预览
  • “越来越接近了”——还需要再迭代一次
  • “方向不对”——让我进一步说明想要什么

如果用户选择“越来越接近了”或“方向不对”，请收集更具体的反馈并继续迭代。支持多轮综合生成，直到用户满意。

然后继续进入 阶段 7：最终预览。

---

阶段 7：最终预览

用户满意后：

1. 创建 .claude-design/preview/ 目录：

   .claude-design/preview/
   ├── page.tsx                    # Preview page
   └── FinalDesign.tsx             # The winning design
   

2. 在 /__design_preview 创建路由

3. 对于重新设计，加入前后对比：

   • 切换开关或分屏视图
   • 并排显示原版和提案

4. 请求最终确认：

问题：确认最终设计？

• 标题：「确认」
• 问题：「准备好定稿此设计了吗？」
• 选项：
  • 「是，定稿」— 继续清理并生成实现计划
  • 「否，需要修改」— 告诉我需要调整的地方
  • 「中止 — 取消所有操作」— 删除所有临时文件，不生成计划

如果选择「否，需要修改」：收集反馈并迭代。 如果选择「中止」：继续执行下方的中止处理。

---

中止处理

如果用户想在流程中的任何时候（不仅仅是最终确认时）取消／中止，可以说：

• 「取消」
• 「中止」
• 「停止」
• 「算了」
• 「不管了」
• 「我改变主意了」

检测到中止后：

1. 确认中止：

   • 「确定要取消吗？这会删除我创建的所有设计实验室文件。」

2. 确认后立即清理：

   • 完全删除 .claude-design/ 目录
   • 删除临时路由文件（app/__design_lab/ 等）
   • 不要生成任何实现计划
   • 不要更新 Design Memory

3. 确认处理结果：

   • 「设计探索已取消。所有临时文件均已清理。如果以后想重新开始，请告诉我。」

---

阶段 8：定稿

用户确认（选择「是，定稿」）后：

8.1：清理

删除所有临时文件：

• 完全移除 .claude-design/ 目录
• 移除临时路由文件：
  • app/__design_lab/（Next.js App Router）
  • pages/__design_lab.tsx（Next.js Pages Router）
  • app/__design_preview/
  • pages/__design_preview.tsx
  • 还原对 App.tsx 的任何修改（Vite）

安全规则：

• 仅删除 .claude-design/ 内的文件
• 仅删除插件创建的路由文件
• 绝不删除用户编写的文件
• 删除前验证文件路径

8.2：生成实现计划

在项目根目录创建 DESIGN_PLAN.md：

# Design Implementation Plan: [TargetName]

## Summary
- **Scope:** [component/page]
- **Target:** [file path]
- **Winner variant:** [A-E]
- **Key improvements:** [from feedback]

## Files to Change
- [ ] `src/components/Example.tsx` - Main component refactor
- [ ] `src/styles/example.css` - Style updates
- [ ] ... (list all affected files)

## Implementation Steps
1. [Specific step with code guidance]
2. [Next step]
3. ...

## Component API
- **Props:**
  - `prop1: type` - description
  - ...
- **State:**
  - Internal state requirements
- **Events:**
  - Callbacks and handlers

## Required UI States
- **Loading:** [description]
- **Empty:** [description]
- **Error:** [description]
- **Disabled:** [description]
- **Validation:** [description]

## Accessibility Checklist
- [ ] Keyboard navigation works
- [ ] Focus states visible
- [ ] Labels and aria-* attributes correct
- [ ] Color contrast meets WCAG AA
- [ ] Screen reader tested

## Testing Checklist
- [ ] Unit tests for logic
- [ ] Component tests for rendering
- [ ] Visual regression tests (if applicable)
- [ ] E2E smoke test (if applicable)

## Design Tokens
- [Any new tokens to add]
- [Existing tokens to use]

---

*Generated by Design Variations plugin*

8.3：更新 Design Memory

创建或更新 DESIGN_MEMORY.md：

如果是新文件：

# Design Memory

## Brand Tone
- **Adjectives:** [from interview]
- **Avoid:** [anti-patterns discovered]

## Layout & Spacing
- **Density:** [preference]
- **Grid:** [if established]
- **Corner radius:** [if consistent]
- **Shadows:** [if consistent]

## Typography
- **Headings:** [font, weights used]
- **Body:** [font, size]
- **Emphasis:** [patterns]

## Color
- **Primary:** [color tokens]
- **Secondary:** [color tokens]
- **Neutral strategy:** [approach]
- **Semantic colors:** [error, success, warning]

## Interaction Patterns
- **Forms:** [validation approach, layout]
- **Modals/Drawers:** [when to use which]
- **Tables/Lists:** [preferred patterns]
- **Feedback:** [toast, inline, etc.]

## Accessibility Rules
- **Focus:** [visible focus approach]
- **Labels:** [labeling conventions]
- **Motion:** [reduced motion support]

## Repo Conventions
- **Component structure:** [file organization]
- **Styling approach:** [Tailwind classes, CSS modules, etc.]
- **Existing primitives:** [Button, Input, Card, etc.]

---

*Updated by Design Variations plugin*

如果更新现有文件：

• 追加发现的新模式
• 根据最新决策更新任何相冲突的指导
• 保持文件简洁且便于执行

---

错误处理

未检测到框架

如果无法确定框架：

• 询问用户：「我无法检测到你使用的框架。你使用的是什么框架？」
• 提供常见选项：Next.js、Vite、Create React App、Vue 等

开发服务器启动失败

如果开发服务器无法启动：

• 检查端口冲突
• 提供手动操作说明
• 建议用户自行启动服务器

路由集成失败

如果无法创建临时路由：

• 改为创建独立的 HTML 文件
• 提供手动预览说明

清理中断

如果清理过程中断：

• 记录已删除和仍存在的内容
• 提供手动清理说明
• 告知用户，不要留下未完成的状态

---

配置选项

该插件支持以下可选配置（通过环境或项目配置设置）：

• DESIGN_AUTO_IMPLEMENT：如果为 true，则在确认后立即实现计划
• DESIGN_KEEP_LAB：如果为 true，则在执行明确的清理命令前不删除实验室文件
• DESIGN_MEMORY_PATH：自定义 Design Memory 文件的路径

---

示例会话流程

1. 用户：/design-variations:design CheckoutSummary
2. 插件检测到：Next.js App Router、Tailwind、pnpm
3. 插件发现：没有现有的设计记忆
4. 插件询问：访谈问题（5 个步骤）
5. 插件生成：设计简报摘要
6. 插件创建：包含 5 个变体的 .claude-design/lab/
7. 插件创建：app/__design_lab/page.tsx
8. 插件启动：pnpm dev
9. 插件输出：“在 http://localhost:3000/__design_lab 打开”
10. 用户在浏览器中查看变体
11. 插件询问：“哪个变体胜出？”
12. 用户：“变体 C，但要修改 X 和 Y”
13. 插件优化：更新变体 C
14. 用户：“看起来不错”
15. 插件创建：位于 /__design_preview 的最终预览
16. 用户：“已确认”
17. 插件：删除所有临时文件
18. 插件：生成 DESIGN_PLAN.md
19. 插件：创建 DESIGN_MEMORY.md
20. 插件：“完成！请查看 DESIGN_PLAN.md 了解实施步骤”