Menü
设计需求收集与澄清。通过多轮追问确认视觉要素和模块 UE 交互，输出结构化设计规范到 Design-Brief.md。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
构建验证、版本管理与发布上线。多轮确认发布目标与推送路径后执行门禁与发布，写入状态与 release notes。用户提到发布、上线、deploy、打 tag、发版、merge 到 main、推远程、构建生产包、创建 PR 时，即使未说 release 也必须使用本 skill。
技术架构设计。调研技术方案、评估开源项目、输出架构决策记录，写入 Tech-Arch.md。在 dev-planner 之前调用。
设计执行。基于 Design-Brief.md 产出原型、设计稿或设计系统。支持 Figma、Pencil、HTML/CSS 原型等多种输出方式。
需求收集与问题澄清。新建或迭代 PRD，通过交互式澄清生成结构化产品需求文档。
系统化调试修复 Bug。五阶段：收集证据→重现用例→分析(含根因归因)→假设→修复→进化记录。支持触发 code-review 和 feedback-writer。
代码审查和质量检查。调度 code-reviewer sub-agent 审查代码，检查是否符合计划和编码标准。
| name | design-brief-builder |
| description | 设计需求收集与澄清。通过多轮追问确认视觉要素和模块 UE 交互，输出结构化设计规范到 Design-Brief.md。 |
通过多轮交互式对话，逐步确认产品的视觉设计要素和模块级 UE 交互方案，最终输出结构化设计规范到 Design-Brief.md。
铁律：视觉要素不完备 + UE 交互未确认，绝不输出设计规范。 逐维度确认，任何维度缺失都必须继续提问。
基于功能驱动设计： 所有设计问题必须从 Product-Spec.md 中已定义的功能模块出发。不做和功能无关的纯视觉讨论。
二次确认原则： 即使用户在需求阶段提过「喜欢暗色主题」「参考 Notion」等视觉偏好，也必须二次确认细节。偏好 ≠ 具体设计参数。
设计理念优先于参数： 先通过产品对标和场景推理确定设计方向，再逐层落地到具体色值、字号、间距。让用户理解「为什么这样设计」，而不是填表式收集参数。
Product-Spec.md 应已存在（至少 MVP 功能已定义）检查项目根目录下是否存在 Design-Brief.md。
情况 A — 不存在： 进入「新建模式」，从 Step 1 开始完整的视觉 + UE 澄清流程。
情况 B — 已存在： 进入「迭代模式」，流程如下：
Design-Brief.md 已存在（<配色主题>，已覆盖 个模块）。你是想：
- 调整视觉要素 — 修改配色、字体、组件风格等
- 新增模块 UE — 为新增的功能模块补充 UE 设计
- 修改已有模块 UE — 调整某个模块的交互或布局
- 重新来过 — 放弃现有设计，从头来
Design-Brief.v<旧版本号>.md），进入新建模式Product-Spec-CHANGELOG.md提问原则：
必须覆盖的 6 个视觉维度（每个都是必填项）：
| # | 维度 | 必须明确的内容 | 完备判定标准 |
|---|---|---|---|
| 1 | 产品对标 | 更接近哪个已有产品（可多个维度各自对标） | 至少 1-2 个对标产品，且明确了借鉴方向和差异点 |
| 2 | 配色方案 | 亮/暗主题 → 主色 → 点缀色 → 中性色 | 每类色彩有明确的 HEX 色值或色域 |
| 3 | 字体与排版 | 字体族、字号层级、行高 | 至少有标题/正文/辅助文本三级规范 |
| 4 | 内容呈现模式 | 沉浸式纯文本 / 块状结构化 / 混合 | 能描述文档/内容区域的视觉骨架 |
| 5 | 组件风格 | 圆角、阴影、间距、按钮可见性、图标 | 每项有明确选择 |
| 6 | 动效策略 | 无动效 / 微动效 / 适度 / 丰富 | 有明确层级定义 |
不要从抽象的「品牌调性」开始。先从具体的产品对标入手，用对比问题锚定方向：
从产品定位来看，这个产品的视觉气质更接近哪类产品？
- A. Notion — 结构化、区块感强、信息密度可控
- B. Linear — 极简高效、线条锐利、减少一切多余元素
- C. Obsidian — 克制专注、Markdown 原生感、让内容主导
- D. VSCode — 开发者工具感、面板布局、深色主导
- 或者其他你想到的产品？
用户选完后追问差异点：「你觉得和 <对标产品> 最大的区别在哪里？更简单、更强大、还是更轻量？」
多维度对标： 不同模块可以参考不同产品。例如「整体布局参考 VSCode 的面板结构，但编辑器体验参考 Notion 的块状编辑」。鼓励用户混合对标。
提炼品牌调性： 对标确认后，帮用户归纳为 3 个形容词，作为后续所有设计决策的基准。
提问顺序不可乱：
第 1 层 — 亮色 / 暗色主题（先定基调）：
这个产品用户的使用场景是？长时间盯着屏幕还是短时间操作？ 基于 <产品定位>，推荐：
- 暗色主题 — 适合长时间沉浸使用、夜间场景、内容创作类产品。对眼睛友好，让内容发光
- 亮色主题 — 适合白天办公、快速操作、企业工具。信息识别快，更正式
你倾向哪个？要不要同时支持切换？
第 2 层 — 主色（定品牌色）：
主色承载产品的第一印象。偏向：
- 冷色系（蓝/青/紫）— 理性、可信、专注
- 暖色系（橙/红/黄）— 活力、创造、温暖
- 无色系（灰/白/黑）— 极致克制，让内容成为唯一的色彩
第 3 层 — 点缀色（决定产品性格）：
点缀色决定了产品的「性格」。你希望产品给人的感觉是：
- 中性低调 — 尽量减少色彩干扰，点缀色仅用于必要的状态区分
- 活力跳脱 — 彩色点缀让界面有亮点，适合创意工具
- 品牌统一 — 有明确的品牌色，贯穿所有交互元素
点缀色覆盖：链接色、成功/警告/错误状态色、选中高亮色。
第 4 层 — 中性色（灰阶体系）：
基于 <亮/暗主题> 选择，确认灰阶范围：
- 背景层：最深/最浅到什么程度？
- 分割线：明显还是弱化？
- 文字层级：主要文字 / 次要文字 / 禁用文字各用什么灰度？
| 子维度 | 说明 | 示例问题 |
|---|---|---|
| 字体族 | 系统默认 / 思源 / Inter / JetBrains Mono 等 | 「偏好像素级控制的等宽字体还是阅读舒适的无衬线字体？」 |
| 字号层级 | 标题/正文/辅助三级 | 「正文舒适阅读字号偏好 14px 还是 16px？」 |
| 行高与字重 | 阅读体验参数 | 「偏紧凑（行高 1.5）还是宽松（行高 1.8）？」 |
这是写作/文档/笔记类产品的核心维度。对于非内容型产品可以跳过，对于内容型产品必须确认：
你希望核心编辑/阅读区的体验更接近哪种？
- A. Markdown 沉浸式 — 纯文本即写即所得，无可见的结构标记，让文字本身成为焦点。类似 iA Writer、Obsidian 编辑模式
- B. 块状结构化 — 标题可见层级、段落有分割线、内容区块分明。类似 Notion，强调信息组织和操控感
- C. 混合模式 — 写作时沉浸式，整理时结构化，可切换
考虑到产品以 <产品定位> 为主，推荐 <推荐选项>。
| 子维度 | 说明 | 示例问题 |
|---|---|---|
| 按钮可见性 | 实心 / 描边 / 幽灵按钮 | 「主要操作按钮希望醒目（实心）还是低调不抢注意力（幽灵按钮）？」 |
| 圆角策略 | 无圆角 / 小圆角(2-4px) / 中圆角(6-8px) / 大圆角(12-16px) | 「界面偏锐利专业还是圆润亲和？」 |
| 阴影层次 | 无阴影(扁平) / 微阴影 / 明显阴影 | 「卡片/弹窗需要阴影来体现层级还是完全扁平？」 |
| 间距密度 | 紧凑 / 适中 / 宽松 | 「信息量大（紧凑）还是追求呼吸感（宽松）？」 |
| 图标风格 | 线性 / 填充 / 自定义 | 「图标用线性简约风还是填充实色风？」 |
幽灵按钮适用于： 极简风格产品、内容型产品（不分散注意力）、工具栏/辅助操作区。如果用户选择极简方向，主动推荐幽灵按钮。
动效方面，你希望产品达到什么程度？
- A. 无动效 — 静态界面，切换直接到位。适合追求极致速度的工具
- B. 微动效 — 仅在必要时使用：hover 变色、输入光标闪烁、加载骨架屏。不增加额外动画时长
- C. 适度动效 — 页面切换有过渡、列表有进入动画、按钮有反馈。体感流畅但不拖沓
- D. 丰富动效 — 品牌动效、插图动画、微交互细节丰富。适合品牌感强的产品
基于你的产品定位（<产品定位>），推荐 <推荐选项>。
如果用户说「不知道」「你定」，基于产品定位主动给出选项：
根据你的产品定位（<产品定位>），推荐以下设计方向：
- A. <对标产品 A> 风格 — <一句话描述适用性>
- B. <对标产品 B> 风格 — <一句话描述适用性>
- C. <自定义方向> — <一句话描述适用性>
推荐 A，因为 <场景推理>。你觉得？
基于 Product-Spec.md 中的功能模块，逐个确认交互设计。
处理规则：
每个模块必须覆盖的 4 个 UE 维度：
| # | 维度 | 必须明确的内容 | 完备判定标准 |
|---|---|---|---|
| 1 | 布局结构 | 页面分区（导航/主区域/侧边栏/底栏）、响应式策略 | 能用文字或 ASCII 描述页面布局骨架 |
| 2 | 交互流程 | 用户操作路径、页面跳转 | 核心操作有清晰的步骤链路 |
| 3 | 信息流风格 | 信息呈现方式（仅适用于有列表/对话/时间线的模块） | 气泡 / 纯文本流 / 紧凑列表 / 卡片，有明确选择 |
| 4 | 状态处理 | 加载态、空数据态、错误态、边界情况 | 每种状态有对应的 UI 表现方案 |
逐模块确认方式（不要一次性问完所有模块）：
模块 1/N：「<模块名>」
布局：该模块在页面中的位置是？（顶部导航 / 侧边栏 / 主内容区 / 独立页面）
交互：核心操作路径是什么？（如：拖入文件 → 自动解析 → 展示结果）
信息流：（如适用）对话/列表的呈现方式？
- 气泡式（有头像/卡片）还是纯文本流（极简信息流，无头像无气泡）？
状态：以下状态分别需要怎样的 UI？
- 加载中：骨架屏 / 进度条 / 旋转动画？
- 无数据：引导提示 / 示例数据？
- 出错：错误提示位置 / 重试按钮？
确认后进入下一个模块。
信息流风格细化：
对于消息/对话/评论/列表等涉及信息呈现的模块，单独确认：
信息呈现方式偏好：
- A. 气泡式 — 每条消息带用户头像、气泡背景、时间戳。适合社交/协作场景
- B. 纯文本流 — 无头像、无气泡，消息之间简单分行。极致简约，适合 AI 对话/命令行风格
- C. 紧凑列表 — 高密度信息，适合日志/数据展示
用户有参考产品时的处理：
如果用户之前提到过参考产品（如「参考 Notion 的编辑器交互」）：
在澄清过程中，如果产品尚未命名，可以自然地提出：
对了，产品有名字了吗？一个好的产品名能让设计有更明确的方向感。
如果用户需要建议，基于产品定位给 2-3 个方向（如 portmanteau、功能描述型、抽象意境型）。
每轮完成后在心里做自检（不输出给用户）：
视觉要素：
维度 1「产品对标」：□ 产品对标 / □ 品牌调性 / □ 全部明确
维度 2「配色方案」：□ 亮/暗主题 / □ 主色 / □ 点缀色 / □ 中性色 / □ 全部明确
维度 3「字体排版」：□ 已明确 / □ 缺失
维度 4「内容呈现」：□ 已明确 / □ 不适用（非内容型产品）
维度 5「组件风格」：□ 按钮可见性 / □ 圆角 / □ 阴影 / □ 间距 / □ 图标 / □ 全部明确
维度 6「动效策略」：□ 已明确 / □ 缺失
模块 UE（逐模块打勾）：
模块 1「<名称>」：□ 布局 / □ 交互流程 / □ 信息流 / □ 状态处理 / □ 全部明确
模块 2「<名称>」：□ 布局 / □ 交互流程 / □ 信息流 / □ 状态处理 / □ 全部明确
...
规则：
.claude/progress.json：current_skill: design-brief-builder, current_step: "视觉+UE澄清完成", milestones 追加「6维度视觉确认 + 个模块 UE 确认完成」在写入 Design-Brief.md 前，汇总给用户最终确认。
摘要要用设计语言描述，不是参数罗列。参考风格：
视觉风格是深色灰阶，结合了 Notion 的结构感和 Obsidian 的克制。布局参考了 VS Code 的面板结构。核心理念是让界面尽量隐形，让文字成为唯一的主角。交互元素全部用幽灵按钮，极简信息流，微动效。整体是一款非常沉浸式的写作产品。
然后附上具体参数确认：
## 设计确认
**产品对标**：<产品 A>（整体布局）+ <产品 B>（编辑器体验）
**品牌调性**：<形容词 1>、<形容词 2>、<形容词 3>
**配色方案**：
- 主题：暗色 / 亮色
- 主色：#XXXXXX
- 点缀色：中性低调 / 活力跳脱 / 品牌统一，色值 #XXXXXX
- 中性色：背景 #XXXXXX，主要文字 #XXXXXX，次要文字 #XXXXXX
**字体**：<字体名>，标题 <N>px / 正文 <N>px / 辅助 <N>px
**内容呈现**：<沉浸式 / 块状结构化 / 混合>
**组件风格**：按钮 <实心/描边/幽灵>，圆角 <N>px，阴影 <描述>，间距 <紧凑/适中/宽松>，图标 <风格>
**动效策略**：<无动效 / 微动效 / 适度 / 丰富>
**产品名称**：<名称>
**模块 UE**：
1. <模块名> — 布局：<描述>，核心交互：<描述>，信息流：<描述>
2. <模块名> — 布局：<描述>，核心交互：<描述>，信息流：<描述>
...
以上是否准确？有没有需要调整的？
用户确认无误后，进入 Step 6。
将确认后的设计规范写入 Design-Brief.md，格式如下：
# <产品名称> — 设计规范
## 1. 品牌与视觉
### 1.1 设计理念
<一段话描述设计理念，参考产品对标，核心理念>
### 1.2 品牌调性
### 1.3 配色方案
| 色彩角色 | 色值 | 用途 |
|---------|------|------|
| 主题 | 暗色/亮色 | — |
| 主色 | #XXX | 主按钮、导航 |
| 辅色 | #XXX | 次要按钮、标签 |
| 点缀色 | #XXX | 强调/链接/状态 |
| 中性色-背景 | #XXX | 页面背景 |
| 中性色-主要文字 | #XXX | 正文 |
| 中性色-次要文字 | #XXX | 辅助说明 |
### 1.4 字体与排版
### 1.5 内容呈现模式
### 1.6 组件视觉规范
（按钮、圆角、阴影、间距、图标）
### 1.7 动效策略
## 2. 模块 UE 设计
### 2.1 <模块名 1>
#### 布局结构
#### 交互流程
#### 信息流风格
#### 状态处理
### 2.2 <模块名 2>
...
---
> 关联：[Product-Spec.md](./Product-Spec.md)
> 变更记录见 [Product-Spec-CHANGELOG.md](./Product-Spec-CHANGELOG.md)
追加到 Product-Spec-CHANGELOG.md：
v<当前版本> → 新增 → 输出设计规范：<设计理念一句话>，配色 <...>，覆盖 <N> 个模块 UE进度 checkpoint：更新 .claude/progress.json：
current_phase: "design"documents.Design-Brief.md：exists: truemilestones 追加「Design-Brief v<版本号> 已输出」设计规范完成后，询问用户：
设计规范已写入 Design-Brief.md。接下来你想：
- A. 产出原型/设计稿 — 调用 design-maker 基于规范生成界面
- B. 直接进入开发 — 跳过设计稿，调用 dev-planner 制定开发计划
- C. 修改设计规范 — 还有什么要调整的
Design-Brief.md — 完整的设计规范文档（设计理念 + 视觉 + UE）Product-Spec-CHANGELOG.md — 追加设计变更记录Product-Spec.md 中列出的功能模块——别为一个不存在的功能设计交互