技能介绍

为什么需要它

Agent 的失败往往不是模型能力问题，而是「该调哪个技能」没被显式决策。一段日志报错，可能该走 superpowers:systematic-debugging，也可能只是一次单行修复，不该触发任何技能。靠记忆规则或临时询问，既不一致，也没法审计。skill-router 把路由本身做成一个可测试的契约：输入是一句用户请求，输出是明确的技能链路，或明确的沉默。

它如何工作

核心是三问分诊，先判断请求属于哪条路径：

BROKEN：报错、崩溃、测试失败、TypeScript 报错、性能回退、安全问题、构建失败、线上事故。事故类任务会切到 opus 并强制 ultrathink。
BUILD：UI 组件、API 端点、数据库 schema、鉴权、AI 功能、第三方集成、CLI 脚本等。多文件新功能走 brainstorming → writing-plans → domain skill，单文件小改动直接进领域技能。
OPERATE：重构、补测试、性能优化、文档、代码评审、部署、PR、迁移、并行任务、继续上次工作。架构级决策同样交给 opus + ultrathink。

路由完成后，技能会以固定格式输出 [skill-router] 公告，包含技能链、模型和思考深度，再写入 ~/.claude/skill_router_log.jsonl 供审计脚本读取。Iron Rule 通过 PreToolUse 钩子拦截 Edit、Write、Task 等写操作，直到下一个技能被实际调用；Stop 钩子则阻止在链路未完成时结束回合。

两条逃生通道值得注意：用户在消息里写 [no-router] 可直接退出并清除待定状态；模型判断路由有误时执行 router_override.py，理由会追加到 skill_router_overrides.jsonl，多次override 后该技能会改为无公告静默让路。

适用边界

单行修复、读代码、问一个事实、跑一条命令、少于三个琐碎步骤，都不触发路由。没有匹配信号时输出空，这是正确行为，不是漏判。
显式 slash-command 如 /ship prod 代表用户已选技能，路由器不重分类。
精度靠 tests/calibration.py 校准，当前基线为路径准确率 100%、技能准确率 95.2%；scripts/learn-from-history.py 会从历史公告和实际调用中找出被忽略或漏掉的模式。
公告格式不可省略，因为用户会 grep '\[skill-router\]' 验证声明与执行是否一致。

它适合把「流程一致性」当成硬约束的工程场景，不适合想自由发挥、又不想被钩子打断的轻量对话。