用途：这是一个轻量级工作流路由器，把工作分派到最小且合适的工作流，避免把清晰、低风险的任务升级成项目。它尊重仓库本地指令和用户明确请求；当两者实质冲突时，应指出冲突并给出建议，而不是默默选择。若仓库存在 Glossary 则使用它，否则使用 workflow-language.md。
主要能力（路由规则）：解释代码区域或流程→explain-codebase；诊断缺陷、失败、不稳定、异常输出或回归→diagnose-issue；明确要求规划，或存在实质歧义、协调、跨领域范围、不可逆性或风险→plan-work；执行已确定范围（来自 Plan、交接、发现、简报、文档任务、修复或重构）→implement-work；写续接提示或文件→write-handoff；评审 Plan、变更、修复轮次或非代码产物→review-work；发现架构改进机会→improve-architecture；在不改变预期行为的前提下简化已界定区域→simplify-work；用一次性原型或逻辑原型回答设计问题→plan-prototype；已安装时，写提交信息或提交变更→commit-work，开或更新 PR、交付堆叠 PR 或运行堆叠合并循环→manage-pr，建立隔离 worktree 或清理陈旧 worktree→manage-worktrees，回答编码规范问题或为结构/验证决策提供依据→coding-standards。
使用方式：多个技能适用时选最具体的；用户点名某技能则使用该技能。清晰低风险工作可直接进行；当执行纪律或续接上下文确有帮助时使用 implement-work。具体架构评审归 review-work；明确选择保持行为的简化用 simplify-work，其他已决定变更用 implement-work，机会或接口形态仍需发现时用 improve-architecture。
成本与权限：问题、研究、工具、产物、委派与验证应与实际不确定性和风险匹配。合并向负责人提出的问题并附建议，不要追问仓库能回答的事实。只研究能实质改变结果的缺口，从本地和第一方证据开始。评审与诊断默认只读，除非用户明确要求修复或实现。除非被要求或授权工作流自然需要，不要创建 Plan、Roadmap、持久文档、交接文件、worktree、提交、PR 或 issue。每个实现阶段结束时，对整阶段范围做一次独立的全新上下文评审；无 Plan 的直接实现视为一个阶段等价评审范围，交付前同样评审。Plan 可在高影响任务或任务组后加评审检查点，低影响任务无需逐个立即评审。不要对评审再做递归评审；对照一手证据核实委派声明，请求范围关闭即停止。工作流状态保存在工作流产物中；持久交付产物不得依赖 Plan 或 Roadmap 文件或工作流相对标识符。
限制：资料未提供具体安装命令、收费、价格、平台支持或效果数据。