技能路由器

在多技能、多 Agent、多模型的环境里，最常见的失败不是“模型不够聪明”，而是路径选错：该先排查异常的直接改代码，该走构建链的顺手做了运维，该用更专精技能的被通用技能顶替。Skill Router 把这类决策显式化：先用 3 问分诊判断任务落在 BROKEN / BUILD / OPERATE 哪条路径，再按路由表给出 Skill + Agent + Model + Thinking 的组合。

解决什么问题

• 路径漂移：没有约束时，Agent 倾向于直接开干，跳过调试、验证、代码评审等必要环节。
• 路由不一致：同样一类“测试失败”，不同会话可能落到不同技能和模型，复现和审计都困难。
• 可见性差：路由决策通常只存在于上下文里，事后无法 grep，也无法被脚本校验。

核心机制

1. 3 问分诊：BROKEN 处理异常、测试失败、构建失败、安全事故等；BUILD 覆盖 UI 组件、API、数据库 schema、AI 特性、第三方集成等新功能；OPERATE 处理重构、补测试、性能优化、文档、评审、部署、合并、迁移等。
2. 路由表：每条信号映射到技能、Agent、模型和思考深度，例如生产事故会落到 superpowers:systematic-debugging + general-purpose + opus + ultrathink，而不是默认用 Sonnet 硬扛。
3. 声明式输出：一旦命中路由，先输出 [skill-router] 公告，再用 ▶ 标注 in-session、via Agent 或 parallel via Agent；步骤完成时追加 [skill-router] Step / done.，整链结束输出 Chain done.。
4. IRON RULE 强制：公告后，未先调用指定技能就使用 Edit、Write、Task 等改动型工具会被 PreToolUse hook 拦截；整轮结束前若仍未调用，Stop hook 会继续阻塞。读取类工具不受影响，方便收集上下文。
5. 目录检查与思考深度：路由表给出通用技能时，会再查本地/远程目录找更具体的 specialist；公告中会按 Thinking 列前置 think.、think hard. 或 ultrathink.，并把事件写入 ~/.claude/skill_router_log.jsonl。
6. 完成门与测试：任何“完成”结论前必须过 superpowers:verification-before-completion；tests/calibration.py 用约 100 条提示评估精确率、召回率和 F1，scripts/learn-from-history.py 则对比公告与实际调用，输出调优建议。

边界与注意

• 没有匹配信号、单行修复、读代码、单条命令或少于 3 个琐碎步骤时，路由器不输出，避免把闲聊误判成重构。
• 用户显式 slash-command 时路由器保持沉默，不会把已有选择重分类；文件系统路径不受影响。
• 覆盖是双向的：用户提示中写 [no-router] 可退出本轮路由；模型也可运行 router_override.py 记录理由。同一技能被 reasoned override 多次后会进入静默降级，成功调用后再恢复。
• 个人规则写在 SKILL.personal.md，优先级高于核心路由表；自定义链和命名链匹配规则需要额外校准，否则会引入噪声。

它不是“更聪明的模型提示词”，而是一套可 grep、可审计、可测试的路由策略：让 Agent 在复杂的技能生态里，先走对路，再动手。