Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From vibeflow
Generates architecture/design documents from approved briefs with built-in problem exploration. Guides through proposal, approval, and transition to tasks. Use when starting a new feature or change that requires design decisions.
npx claudepluginhub ttttstc/vibeflow --plugin vibeflowHow this skill is triggered — by the user, by Claude, or both
Slash command
/vibeflow:vibeflow-designThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
以审批通过的 `brief.md` 为输入。提出实现方案，逐节获得设计审批，产出回答 HOW 的设计文档。
Generates architecture/design documents from approved SRS docs when no prior design exists, proposing 2-3 approaches with trade-offs and securing section-by-section approval.
Orchestrates design workflow from idea to docs: context gathering, clarification, brainstorming, design documentation, planning handoff. Use when starting any design process.
Collaboratively brainstorms architecture, patterns, and trade-offs to produce a design document. Activates on 'design this', 'create a design', 'brainstorm approaches', or 'write a design doc'.
Share bugs, ideas, or general feedback.
以审批通过的 brief.md 为输入。提出实现方案，逐节获得设计审批，产出回答 HOW 的设计文档。
此 skill 已吸收 brainstorming 核心行为：当无 brief 或问题不清晰时，先进行问题探索再进入技术设计。
启动宣告： "正在使用 vibeflow-design — 设计阶段（含问题探索）。"
在你展示设计文档并获得用户批准之前，不得调用任何实现技能、编写任何代码、搭建任何项目。此规则适用于每个项目。SRS 描述系统做什么。设计文档描述怎么做。即使需求很清晰，实现方案（架构、数据模型、技术栈选择）也需要显式决策和用户审批。
每个项目都需要设计。一个 todo list、一个函数工具、一个配置变更——所有项目都需要。"简单"项目正是未经审视的假设造成最多浪费的地方。设计可以很短（真正简单的项目几句话），但你必须展示并获得批准。
按顺序完成以下步骤：
docs/changes/<change-id>/rules/ 提取本次设计适用的约束并写入设计文档docs/changes/<change-id>/design.mdvibeflow-tasks 生成全量交付计划，并停在人工确认闸门终止状态是进入 vibeflow-tasks，并在 tasks 人工确认通过前不得进入 build。
当存在 docs/changes/<change-id>/brief.md 且问题已清晰时，跳过此步骤，直接进入步骤 1。
当无 SRS 或问题定义模糊时，先通过问题探索厘清方向：
优先检查是否存在 docs/changes/<change-id>/brief.md：
一次只问一个问题。优先使用多选题。
通过 AskUserQuestion 提问，聚焦于理解：
使用 AskUserQuestion 格式：
RECOMMENDATION: Choose [X] because [one-line reason]A) ... B) ... C) ...展示 2-3 个实现方案并带有明确权衡：
## 方案 A：[名称]
**摘要**：[1-2 句]
** Effort**: [S/M/L/XL]
**风险**: [低/中/高]
**优点**: [2-3 点]
**缺点**: [2-3 点]
**复用**: [现有代码/模式]
规则：
RECOMMENDATION: Choose [X] because [one-line reason]
使用 AskUserQuestion 展示方案并请求选择：
将问题探索结论写入最终设计文档的"问题定义"和"方案选择"章节，并合并到当前 change 的正式产物中。
python scripts/get-vibeflow-paths.py --jsondocs/changes/<change-id>/brief.md.vibeflow/workflow.yaml 中的 template：
prototype / api-standard → 通常无前端 UI，跳过 UCDweb-standard / enterprise → 通常有 UI，执行 UCD 子步骤docs/changes/<change-id>/ucd.md（如已存在）当 SRS 有 UI 需求且无现有 UCD 文档时，执行以下子步骤生成风格指南：
前端设计约束加载：
skills/vibeflow-design/references/frontend-design-constraints.md在写任何 UI/UX 方案前，先向用户明确这 4 个问题：
规则：
clean and modern 这类空话Tailwind only / CSS Modules only / CSS-in-JS only向用户展示 2-3 个视觉风格选项：
## 风格 A：[名称]
**调性**：[1-2 句描述视觉感受]
**色彩方向**：[主色调倾向 — 暖/冷/中性，高/低对比]
**排版方向**：[衬线/无衬线，几何/人文，密度]
**布局方向**：[卡片/列表，紧凑/宽松，固定/流式]
**目标用户契合**：[最适合哪些 SRS 用户画像]
等待用户选择或提供方向。
定义锚定整个风格系统的具体设计 Token：
颜色调色板：
| Token | Hex | 用途 | 对比度 |
|-------|-----|------|--------|
| --color-primary | #XXXXXX | 主要操作、链接 | >= 4.5:1 |
| --color-bg-primary | #XXXXXX | 主背景 | |
| --color-text-primary | #XXXXXX | 正文 | >= 4.5:1 |
所有对比度必须满足 WCAG AA（正文 4.5:1，大文本 3:1）。
排版比例： 字体族、大小、字重、行高、用途。
Inter、Roboto、system-ui 当作主展示字体间距与布局： 间距 token（--space-xs/sm/md/lg/xl）、圆角（--radius-sm/md/lg）、阴影（--shadow-sm/md/lg）。
图标风格： 线框/填充/双色、图标库（如 Lucide Icons）。
动效预算：
对 UI 清单中的每种组件类型产出文生图提示词：
### 组件：[组件名]
**变体**：默认、悬停、激活、禁用、错误、加载
#### 基础提示词
> [详细文生图提示词，引用颜色 Token、排版 Token、间距]
对每个关键页面/屏幕产出整页文生图提示词。
无论是否执行 UCD 子步骤，统一提取：
列出必须在设计前解决的 SRS 开放问题。
如项目不是从空仓开始，设计阶段默认读取：
docs/overview/CURRENT-STATE.md如上述影响分析文件不存在，先运行：
python scripts/map-change-impact.py --project-root . --source design设计文档必须显式吸收以下内容：
重点模块关键入口风险提示建议先读如果项目根目录存在 rules/，这是设计阶段的一等输入，不是实现阶段才补读的附件。
python scripts/vibeflow_rules.py --project-root . --stage design --language <language> --format markdown --design-section
docs/changes/<change-id>/design.md 的固定章节：## Project Rules And Constraints
禁止跳过： 当 rules/ 存在时，不得省略 ## Project Rules And Constraints 章节。
展示 2-3 个实现方案并带有明确权衡：
## 方案 A：[名称]
**原理**：[1-2 句]
**优点**：[要点列表]
**缺点**：[要点列表]
**最适用于**：[条件]
**NFR 影响**：[该方案如何影响 SRS NFR 阈值]
**第三方依赖**：[关键库/框架及版本]
## 推荐：方案 [X]
**理由**：[为何最适合 SRS 约束和 NFR]
每个方案必须对照 SRS 约束和 NFR 阈值评估。无法满足"Must" NFR 的方案被淘汰。
非简单项目逐节展示并获得审批：
graph）显示层/包/模块及依赖方向graph）显示运行时组件和交互classDiagram）sequenceDiagram）或流程图（flowchart）erDiagram）frontend-design-constraints.md 自查常见模板味陷阱，避免默认 hero / 默认卡片网格 / 默认导航栏graph）标识关键路径简单项目（< 5 个功能）：合并所有章节为单次审批步骤，但仍需包含必要图表和依赖版本。
用户审批设计后，执行 AI 独立深度审查——这是 AI 质量把关，不重复用户审批。
调用 vibeflow-plan-eng-review 对设计文档进行工程评审：
Skill: vibeflow-plan-eng-review
评审内容：架构设计、数据流、测试策略、性能风险、安全边界。
完成后将结论写入 docs/changes/<change-id>/design.md 的 ## Engineering Review 小节。
调用 vibeflow-plan-design-review 对设计文档进行七轮设计评审：
Skill: vibeflow-plan-design-review
评审内容：信息架构、交互状态、用户旅程、AI 污染风险、设计系统一致性、响应式与无障碍。
完成后将结论写入 docs/changes/<change-id>/design.md 的 ## Design Review 小节。
提取两个 review 的关键发现：
## AI 审查结论
**日期**：YYYY-MM-DD
**设计文档**：`docs/changes/<change-id>/design.md`
### 工程审查（vibeflow-plan-eng-review）
- Architecture: [N] issues
- Code Quality: [N] issues
- Test Coverage: [N] gaps
- Performance: [N] issues
- **严重问题**： [列出 critical issues，需在 scope decision 前处理]
### 设计审查（vibeflow-plan-design-review）
- Information Architecture: [N]/10
- Interaction States: [N]/10
- User Journey: [N]/10
- AI Slop Risk: [N]/10
- Design System: [N]/10
- Responsive & A11y: [N]/10
- **待解决设计问题**： [列出影响范围的问题]
基于用户审批的设计方案 + eng review + design review 三方意见，综合判断范围是否需要调整。
| 检查 | 问题 |
|---|---|
| 范围过大 | 设计中是否有 MVP 不需要的功能？哪些可以推迟？ |
| 范围过小 | 设计是否遗漏了对目标结果至关重要的功能？ |
| eng review 风险 | 架构或技术方案是否有重大风险影响范围？ |
| design review 问题 | 是否有严重设计缺陷需要范围调整？ |
产出三选一的决策：
扩展（Expand）：eng/design review 发现当前范围遗漏了高价值、低成本的功能。
保持（Hold）：设计合理，eng/design review 无重大问题。
缩减（Reduce）：eng/design review 发现范围过大或风险过高。
通过 AskUserQuestion 展示 AI 审查结论和范围决策建议：
RECOMMENDATION: [Expand / Hold / Reduce] — [one-line reason]A) 接受推荐 B) 调整范围 C) 先解决 critical issues 再决定如果范围有调整，将决策记录写入设计文档末尾：
## 范围决策
**决策**：[Expand / Hold / Reduce]
**理由**：[简要说明]
**调整**：[如范围有变化，列出具体调整内容]
**eng review 发现**：[N] issues（critical: [N]）
**design review 发现**：[N]/10 overall
保存到 docs/changes/<change-id>/design.md。
执行交接硬要求：
rules/ 存在且有适用规则时，设计文档必须包含 ## Project Rules And ConstraintsBuild Contract TOML 代码块Implementation Contract TOML 代码块Implementation Contract 至少要写出：feature_id、title、priority、dependencies、file_scope、verification_commands 或 verification_stepstasks.md 由下一阶段 vibeflow-tasks 单独生成，用来回答“如何按稳定顺序落地”设计阶段完成后，必须向用户展示：
design.md 的关键方案摘要然后明确请用户确认：
tasks未确认前不得进入 tasks。
设计文档保存并提交后：
tech_stack、项目骨架vibeflow-tasks 生成执行级任务计划所有架构和设计视图必须使用 Mermaid 语法。
| 章节 | 图表类型 | Mermaid 语法 | 必需？ |
|---|---|---|---|
| 架构逻辑视图 | 分层包图 | graph TB | 始终 |
| 架构组件 | 组件交互 | graph LR | 始终 |
| 关键功能 — 结构 | 类图 | classDiagram | 每个功能 |
| 关键功能 — 行为 | 序列图/流程图 | sequenceDiagram/flowchart | 每个功能（至少一个） |
| 数据模型 | ER 图 | erDiagram | 如有持久化 |
| 依赖图 | 依赖树 | graph LR | 如 > 3 个第三方依赖 |
| 开发计划 | 关键路径 | graph LR | 始终 |
| 合理化借口 | 正确响应 |
|---|---|
| "SRS 已暗示了架构" | SRS 描述 WHAT，不是 HOW。展示选项。 |
| "只有一种方式构建" | 至少展示 2 个方案。即使显而易见的选择也需说明权衡。 |
| "用户似乎不耐烦，跳过设计" | 简要说明价值，然后高效执行 |
| "边做边设计" | 前期设计比中途纠正便宜 |
调用者： vibeflow-router（design 阶段）
依赖： docs/changes/<change-id>/brief.md；可选 docs/changes/<change-id>/ucd.md
链接到： vibeflow-tasks（scope decision 通过后）
产出：
docs/changes/<change-id>/design.md（设计文档，含 UI/UX 章节、工程审查、设计审查与范围决策）UCD 行为说明：
ucd.md 已存在：读取 UCD 作为输入，跳过 UCD 生成ucd.md：执行 UCD 子步骤（步骤 1.2）生成风格 Token 和提示词，并保存到 docs/changes/<change-id>/ucd.mdskills/vibeflow-design/references/frontend-design-constraints.md