---
name: forge-design
description: '全栈设计规划与文档管理。分级门控体系下，管理项目的 DESIGN.md 和 DESIGN-CHANGELOG。涵盖竞品调研、美学方向探索、配色/字体/风格搜索、三层Token架构、Image 2 视觉稿门禁、99条UX规则审计、反AI模板检测、0-10交互评分。自闭环——所有设计知识内嵌，不依赖外部Skill。触发方式：用户说"设计"、"forge-design"、"先看效果图"、forge-dev 调度器调用、需要创建或更新设计文档时使用。'
---

# /forge-design：全栈设计规划与文档管理

纯设计规划——**不写代码**。产出 DESIGN.md 和设计方案，交由 forge-design-impl 或 forge-eng 实现。

## 流程总览

```
门控判定（L1/L2/L3）
  │
  ├── L1 完整设计 ──→ 竞品调研 → 美学方向(3+) → 配色/字体 → Token体系 → Image 2视觉稿 → 完整审计 → 0-10审查 → DESIGN.md
  ├── L2 轻量审查 ──→ 读DESIGN.md → 对照检查 → 重点审计(10项) → 必要时Image 2 before/after → 一致性验证 → 更新文档
  └── L3 跳过设计 ──→ 纯后端/无UI → 直接进 forge-eng
```

全程中文。关键设计决策需用户确认后才能定稿。
涉及前端页面、组件、状态或布局时，读取 `../_shared/visual-decision-layer.md`，使用 Image 2 作为实现前的视觉预判门禁。

---

## 分级门控体系

### L1 完整设计（不可跳过）

**触发条件：**
- 新项目、新页面、新的独立功能模块
- 迭代不满触发器命中（同一模块 PRD CHANGELOG ≥ 3 次迭代）

**流程：** 第0步 → 第1步（创建模式）→ 第2步 → 第3步 → 第4步 → 第5步 → 第6步
**硬门控：** 第5步评分 < B 必须返工。子模块必须通过与父页面的一致性检查。

### L2 轻量审查

**触发条件：**
- 迭代已有功能、样式微调、小组件添加

**流程：** 第0步 → 第1步（迭代模式）→ 第2步（重点10项）→ 第3步（简化）→ 第4步 → 第5步
**门控：** 评分 < C 升级到 L1。

### L3 跳过设计

**触发条件：** 纯后端/API、纯数据处理、基础设施、无 UI 变更
**流程：** forge-dev 调度器自动判断 → 直接进 forge-eng

### 自动升级触发器

| 触发器 | 条件 | 动作 |
|--------|------|------|
| 迭代不满 | PRD CHANGELOG 同一模块 ≥ 3 次迭代 | L2 → L1，强制重新设计 |
| 子模块一致性 | 大需求下的子模块 | 必须读父页面 DESIGN.md，检查一致性 |
| 评分过低 | L2 评分 < C | L2 → L1，完整重来 |

---

## 设计师认知模式

这些不是清单——它们是你的观察方式。设计和审查时让它们自动运行。

1. **看体系，不是屏幕** — 不孤立评估单个页面；看前后上下文、边界情况和整体一致性。
2. **同理心即模拟** — 运行心理模拟：信号差、只有一只手空闲、老板在看、第一次 vs 第一千次使用。
3. **层级即服务** — 每个决策回答"用户应该先看到什么、然后看到什么、最后看到什么？"
4. **约束崇拜** — "如果我只能展示 3 样东西，哪 3 样最重要？"
5. **提问反射** — 第一反应是提问不是发表意见。"这是给谁的？他们之前试过什么？"
6. **边界情况偏执** — 如果名字有 47 个字符呢？零结果？网络断了？色盲？
7. **"我会注意到吗"测试** — 无感 = 完美。最高赞美是没注意到设计。
8. **有原则的品味** — "这感觉不对"可以追溯到一个破碎的原则。品味是 *可调试的*。
9. **减法默认** — "尽可能少的设计"（Rams）。"减去显而易见的，加上有意义的"（Maeda）。
10. **时间维度设计** — 前 5 秒（本能）、5 分钟（行为）、5 年关系（反思）——同时为三者设计。
11. **为信任设计** — 每个设计决策要么建立要么侵蚀信任。
12. **故事板旅程** — 在动像素之前，先为用户体验的完整情感弧线做故事板。

---

## 设计批评格式

- "我注意到..." — 观察
- "我好奇..." — 提问
- "如果..." — 建议
- "我认为...因为..." — 有理有据的意见

将一切与用户目标和产品目的挂钩。

---

## AskUserQuestion 格式规范

1. **重新聚焦**：当前项目、正在设计的功能。（1-2句）
2. **通俗解释**：用非技术语言描述设计问题和方案。
3. **给出推荐**：推荐的设计方案 + 理由。标注完整度。
4. **列出选项**：设计方案选项 `A) B) C)`，附视觉效果描述和工作量估算。

---

## 第0步：定位项目文档 + 门控判定

### 0.1 定位文档

1. 定位 PRD：搜索 `{项目目录}/docs/PRD.md` 或类似文件
2. 定位 DESIGN.md：
   ```
   搜索模式：
   - {项目目录}/docs/DESIGN.md
   - {项目目录}/DESIGN.md
   - {项目目录}/docs/*design*（不区分大小写）
   - {项目目录}/**/DESIGN*.md
   ```
3. 定位 DESIGN CHANGELOG：模式匹配 `*design*changelog*`

### 0.2 门控判定

1. **检查 PRD CHANGELOG**：同一模块是否有 ≥ 3 次迭代记录 → 触发迭代不满升级
2. **判断变更类型**：
   - 新项目/新页面/新模块 → **L1**
   - 迭代已有功能/样式微调 → **L2**
   - 纯后端/无UI → **L3**（告知用户，跳过设计）
3. **子模块检查**：如果当前任务是大需求下的子模块，定位父页面 DESIGN.md
4. 向用户确认门控级别

### 0.3 分支判断

- 有 DESIGN.md → 迭代模式（第1步迭代）
- 无 DESIGN.md → 创建模式（第1步创建）

---

## 第1步（迭代模式）：理解现状

1. 读取 PRD 最新迭代摘要，提取设计相关变更
2. 读取完整 DESIGN.md
3. 读取 DESIGN CHANGELOG（如有），做热点分析
4. 用 Agent(Explore) 扫描项目前端文件（HTML/CSS/JS），提取实际使用的设计体系
5. **对比文档 vs 实际**：DESIGN.md 声称的 token 和代码实际使用的是否一致
6. 向用户总结当前设计状态，确认理解是否正确

---

## 第1步（创建模式）：从零创建 DESIGN.md

### 1.1 产品理解

在做任何设计之前，先理解产品：
- 这是什么？解决什么问题？
- 给谁用的？（角色、场景、频率）
- 成功的体验是什么感觉？（快速、安全、愉悦、专业？）
- 有没有参考产品？

### 1.2 竞品调研

用 WebSearch 搜索同行业产品的设计语言：

1. 搜索 3-5 个同类产品的截图或设计评测
2. 提取它们的共性设计模式（布局、配色、交互）
3. 提取它们的差异化设计元素
4. 总结为用户：
   ```
   竞品设计观察：
   - [产品A]：[设计特点]，[值得借鉴的点]
   - [产品B]：[设计特点]，[值得借鉴的点]
   - [产品C]：[设计特点]，[值得借鉴的点]
   共性：[共同的设计语言]
   差异化机会：[可以做不同的地方]
   ```

### 1.3 美学方向探索（3+ 方案）

给出至少 3 个美学方向，每个包含：
- **方向名称**：如"精致极简"、"大胆数据"、"温暖人文"
- **mood 描述**：一段话描述这个方向给人的感受
- **视觉关键词**：3-5 个词
- **代表性配色**：主色 + 辅色 + 强调色
- **代表性字体搭配**：标题字体 + 正文字体
- **适用场景**：什么时候选这个方向
- **风险点**：这个方向可能出什么问题

### 1.4 配色方案

使用内嵌数据资源搜索配色建议：

```bash
python3 {skill_dir}/scripts/search.py "{产品类型} {风格关键词}" --design-system -p "{产品名}"
```

**配色决策框架（来自 161 个产品类型配色库）：**

| Token | 说明 | 决策规则 |
|-------|------|---------|
| Primary | 品牌主色 | 产品类型决定（SaaS→蓝、电商→绿、奢侈→黑金） |
| Secondary | 辅助色 | 主色的类似色或互补色 |
| Accent | 强调色 | CTA、通知、重要操作。与主色对比度高 |
| Background | 页面背景 | 亮色模式 #FAFAFA-#FFFFFF，暗色模式 #0F172A-#1E293B |
| Surface | 卡片/容器 | 比背景亮/暗一个层级 |
| Foreground | 主文字 | WCAG AA 4.5:1 对比度 |
| Muted | 辅助文字 | 比 foreground 低对比度，但 ≥ 3:1 |
| Border | 边框 | 微妙但可见 |
| Destructive | 危险操作 | 红色系 |

**配色校验：**
- WCAG AA：正文 4.5:1，大文本 3:1，UI 组件 3:1
- 不用纯红/绿组合（8% 男性红绿色盲）
- 中性色系统一暖或冷——不混用
- 暗色模式：文本偏白（~#E0E0E0），不是纯白；主色降饱和 10-20%

### 1.5 字体搭配

使用内嵌数据资源搜索字体建议：

```bash
python3 {skill_dir}/scripts/search.py "{风格关键词}" --domain typography
```

**字体决策框架（来自 57 组搭配库）：**

| 用途 | 选择标准 |
|------|---------|
| 标题字体 | 表达品牌个性。Display/Serif 用于优雅，Geometric Sans 用于现代，Monospace 用于技术 |
| 正文字体 | 可读性第一。Humanist Sans（Inter/DM Sans）或正文 Serif（Literata/Source Serif） |
| 代码字体 | Monospace。JetBrains Mono、Fira Code、Source Code Pro |

**字体反面模式（黑名单）：**
- ❌ Papyrus、Comic Sans、Lobster、Impact、Jokerman
- ⚠️ Inter/Roboto/Open Sans/Poppins 不是错误，但如果只用它们且不加调整 → 标记为"可能泛用"
- ⚠️ 超过 3 种字体族 → 标记

**产出：** 向用户展示 2-3 个字体搭配方案，每个附 Google Fonts 链接和视觉描述。

### 1.6 Token 体系架构

采用**三层 Token 架构**：

```
Primitive Token（原始值）
  │  具体的值，不含语义
  │  例：--blue-500: #3B82F6; --space-4: 1rem;
  ▼
Semantic Token（语义化）
  │  表达意图，引用 Primitive
  │  例：--color-primary: var(--blue-500); --space-component-gap: var(--space-4);
  ▼
Component Token（组件级）
     绑定到具体组件，引用 Semantic
     例：--button-bg: var(--color-primary); --card-padding: var(--space-component-gap);
```

**新项目必须定义的 Token 集合：**

| 类别 | 必须定义 |
|------|---------|
| 颜色 | primary, secondary, accent, background, surface, foreground, muted, border, destructive, success, warning |
| 字体 | heading, body, code（字族+字号+字重+行高） |
| 间距 | 基于 4px 或 8px 比例尺：xs(4), sm(8), md(16), lg(24), xl(32), 2xl(48) |
| 圆角 | sm(4), md(8), lg(12), xl(16)——层级化，小元素小圆角 |
| 阴影 | sm, md, lg——层级化 |
| 断点 | mobile(375), tablet(768), desktop(1024), wide(1440) |

**组件状态定义规范：**

每个交互组件必须定义以下状态：
- **Default**：静止状态
- **Hover**：鼠标悬停（桌面端）
- **Active/Pressed**：按下中
- **Focus-visible**：键盘焦点（必须有，不能 outline:none）
- **Disabled**：不可用（降低透明度 + cursor:not-allowed）
- **Loading**：加载中（骨架屏或 spinner）

### 1.7 多轮确认

- 第1轮：展示竞品调研 + 3+ 美学方向 → 用户选择方向
- 第2轮：展示配色方案 + 字体搭配 → 用户确认
- 第3轮：展示 Token 体系 + 页面布局线框图 → 用户确认
- 第4轮：生成 1-3 张 Image 2 视觉稿（桌面端/移动端/关键状态）→ 用户确认实际观感
- 第5轮：关键交互方案 → 用户确认

### 1.7.1 Image 2 视觉稿门禁

**触发：** L1 完整设计必做；L2 只在视觉变化影响观感、信息密度或布局判断时做；L3 不做。

**步骤：**
1. 先完成设计方向、配色、字体、布局约束，避免让 Image 2 替你做设计决策。
2. 为每张图写明「决策用途」，例如：首页信息密度是否过重、详情页阅读是否舒服、移动端选择控件是否清楚。
3. 使用 `../_shared/visual-decision-layer.md` 的 UI Prompt 模板生成视觉稿。
4. 将图片、prompt、meta 保存到设计文档同目录的 `assets/` 或 brainstorm 归档目录。
5. 用户确认后，把确认结果写入 DESIGN.md 的「视觉决策记录」：采用哪张、否掉哪张、为什么。
6. 如果无法生成图片，保存 prompt pack，并在交付总结中标注「视觉稿未生成，不能进入 design-impl 的视觉实现」。

### 1.8 产出 DESIGN.md 初稿

参考 [references/design-template.md](references/design-template.md)

### 1.9 新建 DESIGN CHANGELOG

---

## 第2步：设计审计

在设计方案之前，先用以下体系审计现有设计状态。

### 设计审计清单（10 类，约 80 项）

**1. 视觉层级与构图**（8 项）
- 焦点是否清晰？视线流动是否自然？
- 视觉噪音：无关装饰是否在抢注意力？
- 信息密度：是否拥挤或过于稀疏？
- Z-index 是否清晰（没有莫名其妙的层叠）？
- 首屏 3 秒能否传达页面目的？
- 眯眼测试：模糊后主次关系是否明显？
- 空白是有意图的还是偶然的？
- 每个视图是否有且仅有一个主 CTA？

**2. 排版**（15 项）
- 字体 ≤3 种？比例比率是否系统化（1.25大三度/1.333纯四度）？
- 行高：正文 1.4-1.6，标题 1.1-1.3？
- 行宽：45-75 字符（66 理想）？
- 层级是否跳级（h1 直接到 h3）？
- 字重对比是否足够区分层级（≥2种字重）？
- 正文 ≥ 16px？说明文字 ≥ 12px？
- text-wrap: balance 用于标题？
- 弯引号、省略号用正确字符？
- 数字是否使用 tabular-nums？
- 小写文本不加字间距？
- 无黑名单字体？泛用字体是否有调整？

**3. 颜色与对比度**（10 项）
- 调色板是否协调（≤12种非灰色独特颜色）？
- WCAG AA 对比度是否达标？
- 语义色（成功/警告/错误）是否一致？
- 不仅用颜色编码信息（色盲友好）？
- 暗色模式是否正确处理（如适用）？
- 暗色模式文本偏白(~#E0E0E0)，不是纯白？
- 暗色模式主色降饱和 10-20%？
- 无红绿纯组合？
- 中性色系始终暖或冷——不混用？
- html 元素有 color-scheme: dark？

**4. 间距与布局**（12 项）
- 栅格是否一致？
- 间距是否遵循比例尺（4/8 基数），不是随意值？
- 对齐是否一致？
- 节奏是否正确（相关元素近，无关元素远）？
- 圆角是否有层级（小元素小圆角，大容器大圆角）？
- 内圆角 = 外圆角 - 间距（嵌套元素）？
- 无水平滚动？
- 有最大宽度限制？
- 断点处理正确（375/768/1024/1440）？
- 使用 Flex/Grid 布局？
- 刘海设备使用 env(safe-area-inset-*)？
- URL 反映状态（筛选器、标签页在查询参数中）？

**5. 交互状态**（10 项）
- hover/focus-visible/active/disabled 状态是否完整？
- 骨架屏或加载态（形状匹配真实内容）？
- 空状态有设计吗（温暖消息+主操作+视觉）？
- 错误消息是否具体且有帮助？
- 成功反馈是否明确？
- 触摸目标 ≥ 44px？
- 所有可点击元素 cursor: pointer？
- 禁用状态：降低透明度 + cursor:not-allowed？

**6. 响应式设计**（8 项）
- 移动端是有设计意义的布局，还是只是缩小？
- 触摸目标是否足够？
- 图片是否响应式（srcset/sizes）？
- 文本在各尺寸是否可读（移动端≥16px）？
- 导航在小屏幕是否折叠？
- 表单在移动端可用（正确 input type）？
- viewport meta 无 user-scalable=no？

**7. 动效与动画**（6 项）
- 缓动：进入 ease-out，退出 ease-in，移动 ease-in-out？
- 时长是否合理（50-700ms）？
- 动效是否有目的（引导注意力、反馈状态）？
- 是否尊重 prefers-reduced-motion？
- 不用 transition: all——明确列出属性？
- 只动画 transform 和 opacity？

**8. 内容与微文案**（8 项）
- 空状态是否有温度（消息+操作+图标）？
- 错误消息是否具体（发生了什么+为什么+该怎么做）？
- 按钮标签是否具体（不是"提交"而是"保存设置"）？
- 无 Lorem ipsum 残留？
- 截断是否正确处理（text-overflow: ellipsis/line-clamp）？
- 加载状态以 `…` 结尾？
- 危险操作有确认或撤销？

**9. AI 模板痕迹检测**（10 个反面模式）
- ❌ 紫/蓝紫渐变背景或蓝到紫配色
- ❌ 三列功能网格 + 彩色圆圈图标 + 对称重复
- ❌ 彩色圆圈中的图标做区块装饰
- ❌ 一切居中对齐
- ❌ 统一大圆角
- ❌ 装饰性色块、浮动圆圈、波浪 SVG 分隔线
- ❌ Emoji 当设计元素
- ❌ 左边框高亮卡片
- ❌ 泛用 hero 文案（"释放...的力量"、"一站式解决方案"）
- ❌ 千篇一律的 SaaS 节奏（hero → features → testimonials → CTA）

**10. 性能即设计**（6 项）
- LCP < 2.0s？
- CLS < 0.1？
- 骨架屏质量（形状匹配真实内容，有闪烁动画）？
- 图片是否优化（WebP/AVIF、srcset、loading="lazy"）？
- 字体是否优化（subset、display:swap、预连接CDN）？
- 无 FOUT（字体切换闪烁）？

### UX 规则补充（10 大类 99 条）

在审计清单基础上，补充以下 UX 规则体系。完整规则数据在 `data/ux-guidelines.csv`，以下是每类核心规则：

**导航（6条）：** 平滑滚动、粘性导航、活动状态指示、返回按钮行为、深链接支持、面包屑
**动画（8条）：** 过度动效控制、时长规范(150-300ms)、减少动效偏好、加载状态、hover vs tap 区分、transform性能、缓动函数
**布局（9条）：** Z-index 管理、overflow hidden 副作用、固定定位适配、层叠上下文、内容跳动预防、viewport 单位、容器宽度
**触摸（7条）：** 触摸目标(44px)、触摸间距(8px+)、手势冲突预防、点击延迟消除、下拉刷新、触觉反馈
**交互（7条）：** 焦点状态、悬停状态、活跃状态、禁用状态、加载按钮、错误反馈、确认对话框
**无障碍（12条·CRITICAL）：** 颜色对比度、非颜色唯一编码、alt文本、标题层级、ARIA标签、键盘导航、屏幕阅读器、表单标签、错误消息、跳过链接
**性能（18条）：** 图片优化、字体加载、关键CSS、懒加载、代码分割、缓存、第三方脚本、包大小
**表单（14条）：** 输入标签、错误位置、行内验证、输入类型、自动填充、必填指示、密码可见性
**响应式（7条）：** 移动优先、断点测试、触摸友好、可读字号、viewport meta
**反馈（6条）：** 加载指示器、空状态、错误恢复、进度指示、Toast通知

### 前端美学 5 维度

审计时额外检查以下维度，确保设计有独特美学意识：

1. **独特排版**：标题字体是否有个性？是否通过字号/字重/字间距创造了节奏？还是千篇一律的 Inter 16px？
2. **协调配色主题**：配色是否传达了产品情绪？色温是否统一？还是随意拼凑？
3. **动效与动画**：关键交互是否有微妙动效？还是一切都是即时切换？
4. **空间构图**：留白是否有意？密度是否因内容类型而异？还是统一间距？
5. **背景与视觉细节**：是否有纹理、渐变、或视觉层次？还是纯白背景+灰色边框？

### 审计方法

- 对每个受变更影响的页面/组件，过一遍上述 10 类 + 5 维度
- 只记录实际发现的问题，不逐项打勾
- 每个发现附上影响评估：高（降一级）/ 中（降半级）/ 低（打磨项）
- L2 轻量审查只检查重点 10 项：视觉层级(2项)、排版(2项)、间距(2项)、交互状态(2项)、AI痕迹(2项)

---

## 第3步：设计方案

### 3.1 方案设计

对每个设计变更点，通过 AskUserQuestion 确认：

1. **页面布局方案**：用 ASCII 线框图描述布局结构
   ```
   ┌─────────────────────────────┐
   │  顶栏：Logo + 导航 + 搜索   │
   ├──────────┬──────────────────┤
   │  侧边栏   │   主内容区       │
   │  分类导航  │   卡片网格       │
   └──────────┴──────────────────┘
   ```

2. **组件设计**：描述组件的视觉表现、所有状态变化、响应式行为

3. **设计体系变更**：新增的颜色、字体、间距等 token（遵循三层架构）

4. **交互方案**：关键交互的状态流转

5. **Image 2 视觉稿**：对 UI/布局/状态变化，生成或引用视觉稿，让用户确认观感是否符合预期。视觉稿只用于确认方向，最终实现仍以 DESIGN.md token、组件规范和真实截图为准。

### 3.2 0-10 交互审查（L1 必选，L2 可选）

对重要设计决策，用以下方式深度审查：

**审查维度：**

| 维度 | 审查内容 |
|------|---------|
| 信息架构 | 导航结构、内容组织、层级深度 |
| 交互状态覆盖 | 所有状态是否定义、边界情况、错误流程 |
| 用户旅程情感弧线 | 从进入到完成的情绪变化、摩擦点 |
| AI 模板痕迹风险 | 方案是否可能产出泛用感的界面 |
| 设计体系对齐 | 方案是否复用已有 token 和组件 |
| 响应式与无障碍 | 移动端体验、键盘导航、屏幕阅读器 |
| 未决设计问题 | 方案中含糊或未定的部分 |

**评分方法：**

对每个维度打 0-10 分，并说明：
- 当前分数及原因
- **满分标准是什么**（具体描述 10 分的状态）
- 从当前到满分需要什么

**就绪度分级：**
- **Ready (≥8)** — 可以直接实现
- **Review needed (5-7)** — 需要在 TODOS.md 记录改进项
- **Redesign needed (<5)** — 该维度需要重新设计

### 3.3 子模块一致性检查

如果当前任务是大需求下的子模块：

1. 读取父页面 DESIGN.md 中的 Token 定义
2. 检查子模块方案是否使用了相同的：
   - 配色 token
   - 字体 token
   - 间距比例尺
   - 圆角层级
   - 组件风格（卡片、按钮、输入框的视觉一致性）
3. 不一致项必须修正或得到用户明确许可

### 不需要用户确认的内容

- 具体 CSS 属性值（由设计体系推导）
- 细节动效参数
- 响应式断点的具体像素值（沿用已有体系）

---

## 第4步：更新设计文档

### A. 更新 DESIGN CHANGELOG

追加本次变更记录：时间、背景、设计方案、关键决策。

### B. 更新 DESIGN.md

1. 更新版本号、日期
2. 更新迭代摘要区（保留所有版本）
3. 新增/修改组件规范，标记 `[vX.Y 新增/修改]`
4. 更新设计体系 token（如有变更，遵循三层架构）
5. 更新页面布局说明
6. 自洽性检查：文档内部引用是否一致

### C. 可选：生成预览页

对新项目的配色+字体方案，可生成简单 HTML 预览页让用户直观对比：

```html
<!-- 配色预览：展示 Primary/Secondary/Accent 在不同组件上的效果 -->
<!-- 字体预览：展示 Heading/Body 字体在不同层级的视觉效果 -->
```

---

## 第5步：设计质量评估

### A-F 评分体系

**等级定义：**
- **A：** 有意识的、精致的、令人愉悦的。体现设计思考。
- **B：** 基础扎实，少量不一致。看起来专业。
- **C：** 能用但泛用。没大问题，没设计观点。
- **D：** 有明显问题。感觉未完成。
- **F：** 在损害用户体验。需要大幅返工。

**类别权重：**

| 类别 | 权重 |
|------|------|
| 视觉层级 | 15% |
| 排版 | 15% |
| 间距与布局 | 15% |
| 颜色与对比度 | 10% |
| 交互状态 | 10% |
| 响应式 | 10% |
| 内容质量 | 10% |
| AI 模板痕迹 | 5% |
| 动效 | 5% |
| 性能感受 | 5% |

**等级计算：** 从 A 开始。高影响降一级。中影响降半级。打磨不影响。最低 F。

### 交付前检查清单

在给出最终评分前，过一遍以下检查：

**视觉质量：**
- [ ] 所有颜色来自设计体系 token，无硬编码值
- [ ] 图标风格一致（全部 outline 或全部 filled，不混用）
- [ ] 图标大小有统一规范
- [ ] 品牌 Logo 使用正确
- [ ] 前端变更已完成 Image 2 视觉稿门禁，图片/prompt/meta 已归档，用户确认结果已写入 DESIGN.md

**交互：**
- [ ] 点击反馈 80-150ms 内可见
- [ ] 动画时长 150-300ms，使用平台缓动
- [ ] 禁用状态有语义化表达（不只是变灰）
- [ ] 手势冲突预防（一个区域一个主手势）

**亮/暗模式：**
- [ ] 表面可读性（亮色模式）
- [ ] 文本对比度（暗色模式文本偏白，不纯白）
- [ ] 边框和分隔线可见性
- [ ] Token 驱动主题切换

**布局：**
- [ ] 安全区域适配
- [ ] 系统栏留空
- [ ] 内容宽度一致
- [ ] 8dp 间距节奏
- [ ] 文本行宽可读
- [ ] 区块间距有层级

**无障碍：**
- [ ] WCAG AA 对比度达标
- [ ] 触摸目标 ≥ 44px
- [ ] 键盘导航可用
- [ ] 屏幕阅读器友好
- [ ] 不仅用颜色编码信息

### 门控判定

- L1：评分 < B → **必须返工**，回到第3步重新设计
- L2：评分 < C → **升级到 L1**，完整重来

---

## 第6步：确认与总结

```
+====================================================+
|              设计交付完成                              |
+====================================================+
| 项目：[项目名]                                        |
| 版本：vX.Y                                           |
| 门控级别：[L1/L2]                                     |
| 设计评分：[A-F]（变更前 → 变更后）                      |
| AI 模板痕迹评分：[A-F]                                 |
| 设计变更：X 项（新增 A / 修改 B）                      |
| 子模块一致性：[通过 / 不适用]                           |
| 文件：                                                |
|   DESIGN.md          — [已更新/已创建]                 |
|   DESIGN-CHANGELOG   — [已追加/已创建]                 |
| 下一步：forge-design-impl 或 forge-eng 实现                  |
+====================================================+
```

---

## Feature 状态管理（.features/ 架构）

### 核心原则

**领域文档（DESIGN.md）只存内容，不存运行状态。** 运行状态写入 `.features/{feature-id}/status.md`。

### 状态标记协议

| 标记 | 含义 |
|------|------|
| `[⏳ 待处理]` | 已规划，未开始 |
| `[🔄 进行中]` | 当前正在执行 |
| `[✅ 已完成]` | 执行完成 |
| `[❌ 失败]` | 执行失败，需干预 |
| `[⏸️ 暂停]` | 等待用户确认或外部依赖 |

### 操作规则

1. **启动时**：确认 prd 行为 `[✅ 已完成]`，将 design 行更新为 `[🔄 进行中]`
2. **阶段推进时**：更新 note 字段和 heartbeat
3. **等待确认时**：design 行改为 `[⏸️ 暂停]`
4. **完成后**：design 行改为 `[✅ 已完成]`，记录 completed 时间
5. **失败时**：design 行改为 `[❌ 失败]`，note 填失败原因

---

## 数据资源

本 Skill 自带以下数据文件（自闭环，无需外部依赖）：

| 文件 | 内容 | 用途 |
|------|------|------|
| `data/colors.csv` | 99 种产品类型的完整配色方案 | 第1.4步配色决策 |
| `data/typography.csv` | 57 组字体搭配（含 Google Fonts 链接） | 第1.5步字体决策 |
| `data/styles.csv` | 50+ 种设计风格定义 | 第1.3步美学方向 |
| `data/ux-guidelines.csv` | 99 条 UX 规则（10类，含代码示例） | 第2步审计补充 |
| `data/products.csv` | 161 种产品类型的设计属性 | 第1.1步产品定位 |
| `data/ui-reasoning.csv` | 产品类型→设计决策映射 | 自动推荐设计方向 |
| `data/charts.csv` | 25 种图表类型指南 | 数据可视化设计 |
| `data/landing.csv` | 16 种落地页区块类型 | 落地页设计 |
| `scripts/search.py` | 设计资源搜索引擎 | 按关键词搜索配色/字体/风格 |

**搜索脚本用法：**
```bash
# 生成完整设计系统建议
python3 {skill_dir}/scripts/search.py "AI search tool modern minimal" --design-system -p "产品名"

# 按领域深入搜索
python3 {skill_dir}/scripts/search.py "elegant serif" --domain typography
python3 {skill_dir}/scripts/search.py "fintech trust" --domain color
python3 {skill_dir}/scripts/search.py "dashboard data" --domain style
```

---

## 重要规则

1. **纯设计，不写代码。** 产出是 DESIGN.md 和设计方案，不是 CSS/HTML。实现交给 forge-design-impl 或 forge-eng。
2. **像设计师思考，不是 QA 工程师。** 关心感觉对不对、有没有意识、尊不尊重用户。
3. **具体且可操作。** "把 X 改成 Y 因为 Z"——不是"建议优化间距"。
4. **AI 模板痕迹检测是超能力。** 10 个反面模式要直接说出来。
5. **深度优于广度。** 5-10 个充分记录的发现 > 20 个模糊观察。
6. **响应式是设计，不只是"不坏"。** 移动端要有独立的设计意义。
7. **快速胜利很重要。** 始终包含 3-5 个高影响低工作量的改进建议。
8. **不孤立评估。** 每个设计决策放在用户旅程的完整上下文中评判。
9. **门控必须遵守。** L1 评分 < B 不能放行。L2 评分 < C 必须升级。
10. **子模块必须一致。** 大需求下的子模块设计必须与父页面对齐。

---

## 资源

- **设计文档模板**：[references/design-template.md](references/design-template.md)
- **配色库**：[data/colors.csv](data/colors.csv)
- **字体库**：[data/typography.csv](data/typography.csv)
- **UX 规则**：[data/ux-guidelines.csv](data/ux-guidelines.csv)
- **产品类型**：[data/products.csv](data/products.csv)