| 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