技能调度器

解决什么问题

Agent Skills 是按研发阶段组织的工程流程合集，每个技能编码了资深工程师的特定工作流。但真正干活时，两个问题会立刻浮现：任务来了，我该用哪个技能？复杂任务往往横跨多个阶段，这些技能按什么顺序串联？直接凭感觉挑，很容易漏掉关键阶段，或者把流程跑成走过场。

这个元技能就是一个「技能调度器」：它不写业务代码、不产出业务工件，只负责发现、编排，并在所有技能之上贯彻一组不可妥协的通用行为准则。

核心能力

技能发现（按研发阶段定位）：拿到任务先判定所处阶段，再套用对应技能。典型映射如下：

• 需求还模糊 → interview-me；有粗糙概念 → idea-refine
• 新项目/特性 → spec-driven-development；要拆任务 → planning-and-task-breakdown
• 写测试 → test-driven-development（浏览器类走 browser-testing-with-devtools）
• 实现 → incremental-implementation（UI 走前端、API 走接口设计，高风险代码走 doubt-driven-development）
• 出错 → debugging-and-error-recovery；审代码 → code-review-and-quality 及其专项变体
• 提交/CI → git-workflow-and-versioning、ci-cd-and-automation；上线 → shipping-and-launch

贯彻通用准则（始终生效）：非平凡实现前列出显式假设请用户纠正；遇矛盾先停下来管理困惑，而不是硬猜；发现清晰问题就该驳回时驳回，量化代价并给替代方案；完成后反问能否用更少行数/更少抽象实现，克制过度设计；守住范围，不擅自清理「看似无用」的代码；每个技能都有验证步，验证而非假设，未过验证不算完成。

多技能串联：一个完整特性的典型序列是 interview-me → idea-refine → spec-driven-development → planning-and-task-breakdown → incremental-implementation → test-driven-development → code-review-and-quality → git-workflow-and-versioning → shipping-and-launch。并非每个任务都需要全部技能，编排会按需裁剪。

输出与边界

调度器的输出是一个 SkillPlan 工件：{phase, selected, sequence, assumptions, definition_of_done}。它消费各技能的产出工件来决定下一步，下游技能再产出各自的工件（Spec、TaskPlan 等）供再下游消费。

适用边界要说清楚：任务已明确对应单一技能时，直接走该技能即可，不必绕道元技能；它本身不产出业务工件，只做发现、编排与准则约束。完整的发现决策树、生命周期序列与失败模式见 references/template.md。