用途
vibe-coding 是多轮 vibe-coding 工作流的顶层入口点。它负责把用户的即时指令分类到工作流阶段表中的某一行，然后进行路由：要么交给元数据匹配的可见专家技能（并保留该专家自身的写入、审批、停止与验证规则），要么对由路由器自己负责的行（workflow-control、direct-implementation、maintenance）直接执行工作。它不会授权所选行之外的任何操作。
激活方式
仅在明确信号下激活：宿主技能命令（例如 Claude 的 /vibe-coding 或 Codex 的 $vibe-coding，这些只是示例而非完整列表）、宿主提供的调用信号，或诸如“use vibe-coding”的指令。把“vibe coding”作为风格、标签、引用或示例提及不会激活它。后续相关轮次会继续当前活动工作流，无需新的信号。如果激活时没有携带具体编码指令，它会要求提供指令，并且不选择阶段、不展示路由菜单、不总结可用性。
路由状态
工作流的路由状态保存在对话中：当前目标、当前行、活动产物路径、待定用户决策、已知阻塞、下一路由。审批、继续决策和停止边界都在对话中给出和读取。专家状态（执行进度、评审目标、调试假设、委派预算）保留在专家处。
每个后续相关轮次会被分类为：继续当前工作流、修订当前产物、替换工作流、取消工作流，或无关的普通请求。如果陈旧上下文会改变行为且类别不明确，会先问一个澄清问题再路由。在压缩或长时间中断后，会从最新已知产物路径重新绑定，或要求提供该路径。
目标对齐门控
在分类之前，检查指令是否存在未解决的解读：两种合理解读在是否重写历史、发布或版本化什么、是否销毁或不可撤销、是否有任何内容离开本机等方面存在差异，且本轮没有任何信息能确定是哪一种。只有这种情况才触发门控。门控触发时，路由到可见的目标对齐专家（通常是 vibe-goal-alignment）并停下等待用户回答；若没有可见专家，则自行提出确认问题、说明检查过的可用性来源并停下。
工作流阶段
将即时指令（下一个必需阶段，而非最终目标）分类到恰好一行。每行有匹配条件、负责者（效果）和边界：
- workflow-control：取消或替换工作流、无关的顶层技能调用、陈旧上下文澄清、无关普通请求。路由器负责，不写入任何内容。
- review：git 支持的 diff、工作树、分支、基线引用，或 git 支持的方案/文档变更需要评审；评审/修复循环。由 vibe-review 负责（状态变更），只提交自己验证过的修复，绝不提交被评审的变更。
- debug-and-repair：缺陷报告、回归、先前修复失败、“仍然损坏”反馈、工具/自动化/环境故障、运行时产物不匹配。由 vibe-debug 负责（状态变更）。
- plan-pre-check-walkthrough：在执行前与用户逐项走查或预检已保存的实现方案。由 vibe-plan-review 负责（仅产物），在实现前停止。
- commit-execution：暂存、提交、拆分、修订或修复当前变更的历史。由 vibe-commit 负责（状态变更）。
- writing：文本交付物（注释、文档、变更日志、PR 描述、UI 文案、提交信息文本），无评审目标且无历史操作。由 vibe-writing 负责（仅产物）。
- plan-execution：明确请求执行、应用或继续已知方案或切片。由 vibe-plan-execution 负责（状态变更）。
- code-investigation：关于现有代码的只读问题。由 vibe-code-research 负责（只读）。
- creative-direction-exploration：头脑风暴、备选方案、约定与预期行为检查。由 vibe-brainstorm 负责（只读）。
- implementation-planning：已批准规格加继续请求；需要方案的规格；创建或修订方案。由 vibe-planning 负责（仅产物）。
- direct-implementation：一个具体编辑，其表面、验收和验证已说明或显而易见，无已保存方案且无缺陷报告。路由器负责（状态变更）。
- maintenance：依赖更新、无缺陷报告的构建修复、仅测试编辑、用户明确请求的发布准备、仓库杂务。路由器负责（状态变更）。
- requirements-specification：新的模糊、粗略、矛盾、创意、非技术或规格不足的编码目标；修订或批准当前规格。由 vibe-requirements-spec 负责（仅产物）。
当没有行匹配时，报告没有匹配的专家，继续普通行为，不保留路由状态。
平局裁决
- “Looks good”“ready”“continue”“go ahead”或完成的清单会继续工作流，除非停止条件成立。
- 命名了方案、提供了规格/验收标准/任务清单，或涉及多个表面的请求不是 direct-implementation，而是 implementation-planning，或在目标本身模糊时是 requirements-specification。
- 用户命名的行为变更是 direct-implementation；无行为变更的依赖、构建、仅测试、发布准备或杂务编辑是 maintenance；报告的缺陷是 debug-and-repair，即使修复是依赖变更。
- 提交请求中的提交信息措辞属于 commit-execution，writing 为辅助；仅措辞是 writing。
- 与用户逐项检查的已保存方案是走查；同一方案作为 git diff 是评审。
- 新目标或不同交付物是替换工作流或新行，不是继续。
- 当用户或下游阶段报告绑定的规格或方案有缺陷时，下一轮路由到拥有它的行。
继续与停止条件
请求会携带工作流经过其请求结果所需的所有阶段，无需例行审批问题：“write a spec”结束于规格，“plan X”结束于方案，“build”“implement”或“fix X”继续经过执行、评审和每个验证单元的本地检查点提交。仅在以下情况停下并询问用户：
(a) 遇到未解决的人工风险决策，包括新账户、设备、安装、付费服务或用户必须提供的重大投入； (b) 有东西阻塞工作：前提被反驳；缺失事实或当前工作依赖的未证明项；阶段无法在其范围内修复的验证失败；绑定规格或方案的缺陷；无法与用户自身变更分离的变更； (c) 继续会增加、删除或改变请求的行为或范围，或覆盖明确的用户指令； (d) 用户要求此停止，例如“spec only”或“show me the plan first”，或选择了交互模式。
其他一切（偏好、措辞、约定、排序、测试形态、方法，以及不属于人工风险类别、当前工作不需要、无验收标准依赖的低优先级未知项）作为记录的 AI 选择默认值或假设解决，并报告。
提交选择
只有明确的用户请求、绑定的方案项，或工作流自身的验证检查点才会选择提交。提交前要指明来源：当前用户请求、已批准的绑定方案检查点，或本工作流的验证检查点。
适用场景与限制
适用于需要多轮、分阶段推进的编码工作流，尤其是希望由顶层路由器统一分类、路由并维护状态、同时把具体执行交给专门技能的场景。限制：仅在明确激活信号下工作；不授权所选行之外的操作；遇到人工风险决策、阻塞、范围变更或用户要求停止时必须停下询问；缺失事实时明确报告而不编造。