菜单
VibeFlow框架入口。运行 /vibeflow 开始新项目或继续现有工作流。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
启动 VibeFlow 本地看板，实时查看阶段、功能、产物和最近事件。
查看 VibeFlow 项目当前状态（阶段、进度、待处理项）。
测试阶段的真实浏览器验证底座。用于页面交互、表单、路由、前端 API、视觉状态和运行时问题验证。优先使用 Playwright MCP 做真实交互验证，使用 Chrome DevTools MCP 做运行时诊断；MCP 不可用时回退到本地 Playwright CLI 脚本。
在此仓库中用于在会话开始时路由整个VibeFlow生命周期的工作。
系统测试通过后且工作流要求 UI QA 时使用 — 运行浏览器导向的 QA 验证并生成报告
所有活跃功能通过且全局审查完成后使用 — 发布前运行全面系统测试，对齐 IEEE 829 和 ISTQB
| name | vibeflow |
| description | VibeFlow框架入口。运行 /vibeflow 开始新项目或继续现有工作流。 |
VibeFlow是一个结构化的六阶段工作流程，用于有目的性地、有质量关卡地、持续反思地构建软件。
入口规则先定死：
.vibeflow/state.json 不存在，必须先让用户选择 Full Mode 或 Quick Mode.vibeflow/state.json 已存在，直接沿用其中的 mode，不要重复询问/vibeflow-quick，直接进入 Quick 入口，不再额外问模式对不明确的首次请求，默认推荐 Full Mode；只有在“小范围、低风险、可快速回滚”的改动下，才推荐 Quick Mode。
运行 /vibeflow 后，请按上面的规则处理模式选择：
适用场景：
关键约束：
.vibeflow/state.json 中写明 quick_metadocs/changes/<change-id>/design.md 和 tasks.md压缩：前置分析大幅压缩，但不是“无设计直冲代码”
入口：/vibeflow-quick
适用场景：
完整流程：Spark → Design → Tasks → Build → Review → Test
其中有两个关键人工确认闸门：
Spark 收口后，必须展示方向和范围总结，由用户确认是否进入 DesignTasks 不是走过场，必须先展示本次变更的全量交付计划并获得人工确认，才允许进入 Build入口：/vibeflow（选择 Full Mode）
VibeFlow是一个严谨的软件开发框架，强调在构建之前思考、在每个阶段验证、持续改进。它专为质量、可维护性和清晰进度重要的项目而设计。
| 阶段 | 目的 | 关键产出物 |
|---|---|---|
| 1. Spark（灵感迸发） | 灵感探索、问题框定、DeepResearch、复杂度扫描、CEO 价值评估 | docs/changes/<change-id>/brief.md |
| 2. Design（设计） | 技术设计 + 三视角评审 | docs/changes/<change-id>/design.md |
| 3. Tasks（任务化） | 执行级 handoff，生成稳定可消费的 tasks.md，并等待人工确认 | docs/changes/<change-id>/tasks.md |
| 4. Build（构建） | 通过TDD、质量关卡、规范审查实现功能 | feature-list.json |
| 5. Review（审查） | 跨功能的整体变更分析 | 审查报告 |
| 6. Test（测试） | 系统测试和QA验证 | 测试报告 |
feature-list.json中跟踪对于新项目或首次设置，按顺序运行以下命令：
使用vibeflow-spark skill来探索灵感、确定方向并进行价值评估。
使用vibeflow-design编写技术设计。
使用vibeflow-tasks生成执行级任务计划。
Design 确认后先进入 Tasks。
Tasks 展示完整交付计划并获批后才进入 Build。
在 Claude Code 插件里，Build 的默认路径不是逐段手动推进，而是进入 Build 后自动继续后续链路。
只有在调试单个内部子步骤时，才单独调用 vibeflow-build-init 或 vibeflow-build-work。
在任何VibeFlow工作开始之前，验证环境是否正确设置。
运行以下命令确保pre-commit钩子处于活动状态：
ls -la .git/hooks/pre-commit
如果钩子未安装，初始化它们：
git config core.hooksPath .githooks
VibeFlow需要在仓库根目录有一个VIBEFLOW-DESIGN.md。检查：
cat VIBEFLOW-DESIGN.md
如果此文件不存在，必须先完成 Spark、Design 和 Tasks 阶段来创建相关交付产物。
列出所有vibeflow-*技能：
ls skills/vibeflow-*/
预期技能：
如果您处于Build阶段，验证feature-list.json存在：
cat feature-list.json
目的：默认先通过 Office Hours 做问题框定，确认验收标准；再做复杂度扫描、按需 DeepResearch、可选 Roundtable 和 CEO 价值评估。
何时进入：项目开始或面对不清晰的问题时。
关键产出物：docs/changes/<change-id>/brief.md
使用的技能：
vibeflow-sparkvibeflow-office-hours（默认进入）vibeflow-deepresearch（按需）vibeflow-roundtable（可选）退出标准：问题框定完成、验收标准已确认、方向明确、价值评估完成，并由用户确认是否进入 Design。
目的：技术设计 + 三视角评审。
何时进入：Spark 阶段完成后。
关键产出物：
docs/changes/<change-id>/design.md使用的技能：
vibeflow-design退出标准：技术设计完成，design.md 已包含工程审查、设计审查和范围决策结论，并由用户确认是否进入 Tasks。
目的：把设计翻译成 execution-grade tasks.md，为 Build 提供正式交接输入。
何时进入：Design 阶段完成并经用户确认后。
关键产出物：
docs/changes/<change-id>/tasks.md使用的技能：
vibeflow-tasks退出标准：tasks.md 完成、展示为全量交付计划并获人工确认，且可被 Build 直接消费。
目的：从 Build 开始默认自动接管后半程执行链路。
何时进入：Tasks 阶段完成并经用户确认后。
关键产出物：feature-list.json
默认执行方式：
build 后，不再逐段停顿等待用户build -> review -> testdone、阻塞、或需要人工确认子技能（默认作为内部子步骤 / fallback）：
vibeflow-build-init - 初始化构建产物（运行一次）vibeflow-build-work - 编排功能流程vibeflow-tdd - 红-绿-重构循环vibeflow-quality - 覆盖率和变异测试关卡vibeflow-feature-st - 功能验收测试（与 spec-review 并行）vibeflow-spec-review - 每个功能的合规性审查（与 feature-st 并行）并行执行：Quality Gates 通过后，Feature-ST 和 Spec-Review 通过 Agent 工具并行执行。
退出标准：feature-list.json中的所有功能标记为完成并通过，然后自动继续进入 Review/Test。
目的：跨整个分支或差异的整体变更审查，发现跨功能问题。
何时进入：所有功能通过Build阶段后。
使用的技能：
vibeflow-review并行执行：结构审查、回归检查、完整性检查通过 Agent 工具三路并行执行。
退出标准：生成的审查报告没有阻塞性问题。
目的：系统级测试和QA验证，确保整个系统端到端工作。
何时进入：Review阶段通过后。
使用的技能：
vibeflow-test-system - 集成和系统测试vibeflow-test-qa - 面向浏览器的QA验证并行执行：回归测试通过后，集成测试、E2E 场景、NFR 验证、探索性测试通过 Agent 工具四路并行执行。
退出标准：所有系统测试通过，QA报告生成没有阻塞性问题。
VibeFlow支持四种工作流程模板。根据项目范围、团队规模和治理要求进行选择。
使用场景：构建快速原型、概念验证或MVP，其中UI是可选的或推迟的。
特点：
最适合：黑客马拉松、POC、内部工具实验。
使用场景：构建具有前端、后端和潜在UI工作的完整Web应用程序。
特点：
最适合：面向客户的Web应用程序、SaaS产品。
使用场景：构建后端优先项目，其中主要交付物是API或服务。
特点：
最适合：微服务、API产品、后端系统。
使用场景：大型团队、严格治理要求或受监管环境。
特点：
最适合：企业软件、安全关键系统、受监管行业。
问题：不定义问题就直接跳入代码会导致范围蔓延、优先级不清和返工。
预防：在任何实现之前始终完成 Spark 阶段。docs/changes/<change-id>/brief.md 产物必须存在并经过价值评估。
问题：在没有批准的需求或设计的情况下尝试构建会导致不对齐和昂贵的返工。
预防：每个阶段都有明确的进入标准。在Spark、Design 和 Tasks 完全批准之前不要进入Build。
问题：在临时笔记或记忆中跟踪功能会导致功能遗漏、状态不清和集成失败。
预防：在Build阶段将feature-list.json作为所有功能状态的单一事实来源。
问题：跳过TDD、覆盖率阈值或变异测试来"节省时间"会引入技术债务和回归。
预防：质量关卡是不可协商的。一个功能直到所有四个关卡都通过才算完成。
问题：只关注每个功能的审查会忽略跨功能交互、隐藏依赖和系统性问题。
预防：在进入Test之前，始终在Build之后运行vibeflow-review。
以下子技能支持 VibeFlow 框架：
| 技能 | 目的 |
|---|---|
vibeflow-router | 在会话开始时路由整个VibeFlow生命周期的工作 |
vibeflow-wiki | 维护 docs/overview/ 轻量 RepoWiki 层，负责中文格式、生成区块、局部刷新和 freshness 检查 |
vibeflow-spark | 灵感迸发：编排 Office Hours、复杂度扫描、DeepResearch、Roundtable、CEO 价值评估和 Spark 收口确认 |
vibeflow-office-hours | Spark 默认起点：做问题框定、范围梳理和验收标准确认 |
vibeflow-deepresearch | 深度调研：竞品分析、技术栈分析、能力矩阵、产品护城河调研 |
vibeflow-roundtable | 多角色圆桌讨论，用于在 Spark 中可选审视方向和范围 |
vibeflow-design | 在初始化之前编写技术设计（含 UCD 内联：视觉风格、Token、组件提示词） |
vibeflow-tasks | 生成 execution-grade 全量交付计划，并在人工确认后交给 Build |
vibeflow-build-init | Build 内部准备步骤：初始化实现产物 |
vibeflow-build-work | 驱动功能通过TDD到质量关卡再到规范审查 |
vibeflow-tdd | 构建阶段内的红-绿-重构步骤 |
vibeflow-quality | 构建期间覆盖率和变异质量关卡 |
vibeflow-feature-st | 构建期间的功能级验收测试 |
vibeflow-spec-review | 每个功能对需求和设计的合规性审查 |
vibeflow-review | 构建后跨功能的整体变更审查 |
vibeflow-test-system | 构建完成后的系统级测试 |
vibeflow-test-qa | 系统测试后的浏览器导向QA验证 |
vibeflow-browser-testing | 测试阶段的真实浏览器验证底座：对页面交互类改动采集 screenshot、console、network、a11y 等运行时证据 |
vibeflow-learn | 独立学习流：把陌生领域学习、研究写作和资料到输出过程工程化，不写入主链路状态 |
vibeflow-status | 插件可见状态入口：输出当前 phase、恢复原因、建议下一步和推荐查看文件 |
vibeflow-dashboard | 插件可见看板入口：启动本地 dashboard，展示 workflow 状态、feature 状态和最近事件 |
VIBEFLOW-DESIGN.md存在于仓库中时，始终在会话开始时读取skills/vibeflow-router/SKILL.mdfeature-list.json**作为单一事实来源。skills/**下。VIBEFLOW-DESIGN.md视为仓库的产品契约。