用途：spec-orchestrator 负责技能路由与工作流编排。它选择 Inline Plan 或 Spec-backed Plan，路由到正确的工作流技能，并管理各阶段之间的转换。其核心规则是：当存在实现选择时，在人类审阅并批准书面计划之前不得编写代码；纯机械性改动（如拼写错误或精确的单行替换）可跳过规划。
主要能力：选择并声明规划模式；路由到 spec-brainstorm、spec-plan、spec-implement、spec-finish、code-subagents 等技能；管理硬性转换与迭代回退。Inline Plan 为默认模式，适用于边界清晰、已充分理解的工作，路由到 spec-plan 并显式选择 Inline 模式，在对话中给出简明计划、不产生规划产物或跟踪条目，批准后直接实现，不调用 spec-implement、spec-finish 或 code-subagents。Spec-backed Plan 适用于存在具体信号时，如人类明确要求规格或持久化规划产物、需求或边界需先探索、工作实质改变架构/公共契约/数据模型/跨系统行为、多个依赖子系统需分解与依赖跟踪、计划需跨对话留存用于交接或审计，路由经 spec-brainstorm，产出 design.md 与 plan.json。
使用方式：先由 spec-orchestrator 选择并声明模式，再按路由执行。普通有界工作走 spec-plan（Inline 模式）→ 批准 → 直接实现；重大工作或明确要求规格走 spec-brainstorm → spec-plan（Spec-backed）→ 批准 → spec-implement → spec-finish。硬性转换规定：spec-brainstorm 后进入 Spec-backed 模式的 spec-plan；批准的 Inline Plan 直接实现；批准的 Spec-backed Plan 进入 Spec-backed 模式的 spec-implement；spec-implement 后进入 spec-finish。
适用场景与限制：适用于需要纪律化规划与技能路由的开发任务。工作流并非纯线性，存在研究→研究、计划→研究、实现→计划、实现→研究、完成→实现等回退。同一问题循环 2 次以上应停下询问人类。Inline 实现须避开 main/master（除非人类明确允许）、留在批准范围内、运行计划中每项验证、审查最终 diff，且未经明确指示不得提交、推送或开 PR。资料未提供安装命令、收费与平台信息。