forge-design-impl

文档落地路径：遵循 forge-doc-policy 规范。完整白名单 + frontmatter schema 见 ~/.claude/skills/forge-doc-policy/doc-paths.md。 当前文档加载顺序：先读项目 CLAUDE.md、docs/README.md、docs/INDEX.md， 再读 docs/DESIGN.md 当前真相源和相关模块附录；历史 changelog/raw 只在追溯旧决策时读取。 详细规则见 ~/.claude/skills/_shared/current-doc-loading.md。

/forge-design-impl：设计实现

将 DESIGN.md 的设计规范转化为代码。只改样式和布局，不改业务逻辑。

前置条件

1. DESIGN.md 必须存在且已通过 forge-design 审核（评分 ≥ B）
2. 如果有 .features/{feature-id}/status.md，确认 design 行为 [✅ 已完成]
3. 读取 docs/README.md、docs/INDEX.md、docs/DESIGN.md 当前真相源和本次涉及的模块附录，理解设计体系 token、组件规范、页面布局
4. 如果 .features/{feature-id}/feature-spec.md、DESIGN.md 或模块附录中有 Image 2 / Figma / 视觉稿链接，读取并作为观感参考；实现真相源仍是 DESIGN.md 的 token 和组件规则

---

流程

读取 DESIGN.md → 识别实现清单 → 逐项实现 → 每项自检 → 原子提交 → 全部完成后质量验证

---

第1步：识别实现清单

从 DESIGN.md 中提取需要实现的设计变更：

1. 读取 .features/{feature-id}/status.md / feature spec 中的设计交付项；如需追溯历史，再读 docs/CHANGELOG.md 顶部索引和相关 DESIGN-CHANGELOG.md 条目
2. 列出具体实现项，每项包含：
   • 变更内容（如"卡片组件圆角从 8px 改为 12px"）
   • 涉及文件（定位 CSS/样式文件）
   • 预计改动量（小/中/大）
3. 向用户展示清单，确认后开始实现
4. 若存在视觉稿，额外列出：
   • 视觉稿路径
   • 用户确认的关键观感（如信息密度、主次层级、空态情绪）
   • 实现后需要用真实截图对比的页面/状态

---

第2步：实现设计变更

宿主是 Claude Code 时，样式代码由 Codex 写：调用 codex-delegate，任务书里写明以 DESIGN.md 哪个模块和哪些 token 为准、以下实现原则必须遵守；Claude 截图验收后再走第 3 步提交。宿主是 Codex 时直接写。

实现原则

1. CSS 优先

• 优先修改 CSS/样式文件，而非组件结构
• CSS 修改更安全、更可逆
• 只在布局变更时才改 HTML 结构

2. Token 驱动

• 所有样式值引用 DESIGN.md 定义的 token
• 不硬编码颜色值、字号、间距
• 使用 CSS 变量或 Tailwind 配置中的 token

3. 遵循现有代码风格

• 不引入新的 CSS 方法论
• 如果项目用 Tailwind，用 Tailwind；如果用 CSS Modules，用 CSS Modules
• 不为"更好"而重写不相关的样式

4. 响应式必须

• 所有变更都要考虑移动端
• 移动端不是缩小版桌面——要有独立的设计意义
• 断点处理遵循 DESIGN.md 定义的断点

反 AI 模板编码指导

实现时主动避免以下泛用模式：

排版：

• 不要所有文本都 text-align: center
• 标题用 DESIGN.md 指定的字体，不要默认 Inter
• 行高、字间距遵循设计体系，不用浏览器默认值

配色：

• 不要用紫色渐变做英雄区背景
• 不要用彩色圆圈包裹图标
• 颜色来自 token，不要随意用 Tailwind 调色板

布局：

• 不要千篇一律的三列等宽网格
• 不要所有区块等高
• 留白要有意——不是统一的 py-20
• 圆角要有层级——按钮小圆角，卡片中圆角，模态大圆角

组件：

• 不要左边框高亮卡片（border-left: 3px solid accent）
• 不要用 emoji 做列表图标
• 不要装饰性浮动色块