用途
vibeflow-router 用于在会话开始时路由整个 VibeFlow 生命周期的工作。它不直接执行具体开发任务，而是确定当前阶段并把工作交给对应的 skill 或脚本。路由器是文件驱动的：阶段仅从 scripts/get-vibeflow-phase.py 确定，绝不从对话历史推断。
VibeFlow 暴露两种开发模式：
- Full Mode（完整流程）：阶段依次为 Spark、Design、Tasks（以上为人工阶段），随后进入 Build、Review、Test 的自动接管链路，可选阶段为 Ship、Reflect。
- Quick Mode（快速开发）：压缩前置分析，保留最小设计和任务清单，通过 Quick 准入校验后直接进入 Build。适用 Bug fix、小改动、配置更新、测试/文档修补；不适用于新功能、认证/支付/安全/数据迁移、多服务多数据库或架构变更、UI 重设计。
模式选择规则：.vibeflow/state.json 不存在时，属于首次进入，必须先让用户明确选择 Full Mode 或 Quick Mode；文件已存在时直接沿用已有 mode，不自动改写也不重复询问；/vibeflow-quick 是显式 Quick 直达入口，不需再问模式。VibeFlow 当前不会自动推断首次进入应该用哪个 mode。
主要能力
会话开始协议（每个会话开始无例外遵循）：
- 运行
python scripts/get-vibeflow-phase.py确定当前阶段，返回 increment、spark、design、tasks、build、review、test、ship、reflect、done。 - 注入会话上下文，读取
.vibeflow/state.json、phase_history、runtime，以及docs/overview/下的项目级文档、feature-list.json，并运行python scripts/get-vibeflow-paths.py --json解析产物路径，格式化输出 Session Context 摘要。 - 检查增量：
cat .vibeflow/increments/queue.json 2>/dev/null || echo "No pending increments"，有待处理增量时先处理。 - 根据阶段路由到对应处理器。
- 检查 overview freshness：优先读取
.vibeflow/wiki-status.json，不存在时回退看 CURRENT-STATE.md 的文档同步状态段落。若任一正式 overview 文档缺失或 stale，则在进入 Spark/Design/Review/Ship 前优先调用skills/vibeflow-wiki/SKILL.md。
阶段路由表（关键产出物）：quick 产出 state.json（含 quick_meta）与 design.md、tasks.md；increment 更新 feature-list.json；wiki 产出 overview 文档与 wiki-status.json；spark 产出 brief.md；design 产出 design.md；tasks 产出 tasks.md；build 更新 feature-list.json；review 产出 verification/review.md；test 产出 verification/；ship 产出 RELEASE_NOTES.md；reflect 产出 retro 日志。
Build 后自动继续规则：当阶段为 build、review、test、ship、reflect 时，默认行为不是停在子阶段等待用户继续，而是执行当前子步骤后立即重新运行阶段检测脚本，若下一阶段仍属于实施阶段则继续自动推进，直到 done、审查/测试失败回到 build、命中人工确认点或出现阻塞。命令行无人值守、CI 执行或 dashboard 配套运行时，使用 python scripts/run-vibeflow-autopilot.py --project-root .。
使用方式
各阶段的操作：
- increment：读取
scripts/increment-handler.py获取协议，按 FIFO 处理每个增量，更新 feature-list.json，并同步 history.json 与 phase_history。 - spark：使用
skills/vibeflow-spark/SKILL.md，默认先进入 Office Hours 做问题框定并让用户确认验收标准，完成复杂度扫描，由用户选择是否执行 DeepResearch，调研后可选进入 Roundtable，最后完成 CEO 价值评估，输出 brief.md，收口后必须向用户总结方向与范围并确认是否进入 design。 - design：使用
skills/vibeflow-design/SKILL.md，输出 design.md，含 UCD（如需）、用户审批、AI eng review、AI design review、scope decision 等内置步骤，评审结论汇总到 design.md 的 review summary 章节。 - tasks：使用
skills/vibeflow-tasks/SKILL.md，输出 tasks.md，必须展示全量交付计划并等待人工确认，确认前不得进入 Build。 - build：开始自动继续后续链路，先执行准备步骤，再用
skills/vibeflow-build-work/SKILL.md按优先级遍历 feature-list.json 实现功能。 - review：运行
skills/vibeflow-review/SKILL.md，输出 review.md，失败则自动回到 build。 - test：运行
skills/vibeflow-test-system/SKILL.md；涉及页面交互、表单、路由、前端 API 或 UI 状态切换的项目，必须调用skills/vibeflow-browser-testing/SKILL.md做真实浏览器验证；UI 项目再运行skills/vibeflow-test-qa/SKILL.md。 - ship：运行
skills/vibeflow-ship/SKILL.md，生成 RELEASE_NOTES.md，更新 feature-list.json。 - reflect：运行
skills/vibeflow-reflect/SKILL.md，输出 retro 日志。 - done：生成完成摘要（阶段列表、功能计数、耗时、retro 链接）。
适用场景
适用于采用 VibeFlow 框架、需要按阶段推进开发流程的项目，尤其是希望会话开始自动识别当前阶段、自动继续 Build 后续链路、以及通过文件状态而非对话记忆驱动流程的团队与个人。
限制
硬规则是不可协商的，包括：供应商中立命名（用 Vector store、LLM、Embedding model 等别名，而非具体产品名，design.md 明确要求时可例外）；阶段必须从阶段检测脚本读取，脚本缺失时从 phase_history 重建并请用户确认；feature-list.json 是构建顺序、状态、依赖、阻塞的事实来源；进入 Build 后默认自动继续后续链路，除非用户明确要求单阶段调试；phase_history 仅追加，不编辑、删除或重排序；未经用户同意不得阶段回归；产物保持同步；增量队列按 FIFO 处理，不跳步不并行。
进入 Spark 或 Design 前还需执行 Reverse-Spec Pre-Flight Check：检查 overview 文档是否存在且新鲜，检查项目根目录是否含源文件（.py、.ts、.tsx、.js、.jsx），包含时在首次进入提示用户可运行 /vibeflow-reverse-spec 刷新 overview 文档。
更详细的阶段参考文档见 skills/vibeflow-router/references/ 目录。