| name | taxue-skill |
| version | 2.8 |
| description | Skill 工程工具箱——诊断、改造、优化、发布。
触发：/taxue-skill、/txs、skill优化、skill诊断、帮我看看这个skill、触发不准确、token消耗、skill太复杂、技能优化。
EN: "optimize skill", "skill diagnosis", "skill not triggering", "debug skill", "refine triggers", "reduce token usage".
不触发：从零新建 skill → taxue-build（skill 是优化已有的）。
|
taxue-skill：Skill 工程工具箱
让 skill 更好用，不是更复杂。
你的任务：诊断、改造、优化、发布 Agent Skill。
六种改造模式
| 模式 | 触发 | 做什么 |
|---|
| 诊断 | 「帮我看看这个skill」 | 分析问题，不改 |
| 优化 | 「token消耗太大」「太慢」 | 减少冗余，提升效率 |
| 触发优化 | 「skill触发不准确」 | 重写 description 和触发词 |
| 边界优化 | 「skill做了不该做的事」 | 收窄边界，明确边界 |
| 评估 | 「帮我评估这个 skill 的效果」 | 生成测试用例 → 执行 → 度量 → 改进 |
| 重构 | 「skill太复杂」 | 拆分/合并/简化 |
诊断维度
- 触发率：description 是否覆盖足够多的触发场景？
- 边界清晰度：边界声明是否明确？
- token 效率：有没有冗余内容？
- 路由完整性：下游协作是否覆盖？
- 上下文效率：有没有可以按需加载而非预加载的内容？超过 150 行的 SKILL.md，考虑把部分内容移到 references/ 里，用到的时候才读。上下文是有限资源，每个 token 都在消耗注意力预算。
- 流程清晰度：步骤是否可执行？
优化原则
- 触发词要具体：不是「帮我」，是「帮我拆一下」「帮我看看这个skill」
- 边界要明确：什么不做，比什么做更重要
- token 要精简：每个字都要有存在的理由
- 流程要可执行：步骤要具体，不要抽象
自诊断
目标设为自身路径时，完整执行六项诊断，输出自诊断报告后直接修改自身。
评估模式
想评估一个 skill 到底好不好用，最快的办法是让它跑一遍真实场景。
先把测试用例准备好。不用多，10 到 20 个足够。每个用例说清楚三件事：用户会说什么、skill 应该怎么做、skill 不应该做什么。七成常见场景、两成边界情况、一成异常输入——这个比例就行。
然后逐个跑。看几件事：有没有正确触发或路由、输出能不能直接用、有没有遗漏或废话。
跑完算三个数。路由准不准——正确触发的比例。输出能不能直接用——不需要追问或修正的比例。平均每次消耗多少 token。低分用例的共同模式，就是问题所在。针对性改 SKILL.md，重新跑，直到两个指标都达标：路由准确率超过九成，输出可用率超过八成。
几个要点。观察 skill 在真实场景中的行为，基于观察迭代，不要预先假设 agent 需要什么。让 agent 自己跑一遍，看它卡在哪、哪里跳了不该跳的步骤、哪里给了笼统的建议——这些比任何预设的改进方向都更有用。
下一步建议（条件触发）
诊断完成后，根据结果判断是否推荐下一步。不是每次都推荐，只在结果明确指向另一个 skill 时才说一句。
| 结果条件 | 推荐话术 |
|---|
| 诊断发现 skill 问题太多，不如从零重建 | 「修不如重建。用 /taxue-build 重新搭一个。」 |
| 需要创建全新的 skill（非优化已有的） | 「你要的是新建，不是优化。用 skill-creator。」 |
DO NOT
- 从零创建新 skill →
skill-creator（taxue-skill 做初步诊断和路由，不做完整创建流程）
- 需要深度结构性审计 →
skill-auditor（taxue-skill 做问题分类，auditor 做深度执行）
taxue-skill v2.8
