taxue-skill

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太复杂」	拆分/合并/简化

---

诊断维度

1. 触发率：description 是否覆盖足够多的触发场景？
2. 边界清晰度：边界声明是否明确？
3. token 效率：有没有冗余内容？
4. 路由完整性：下游协作是否覆盖？
5. 上下文效率：有没有可以按需加载而非预加载的内容？超过 150 行的 SKILL.md，考虑把部分内容移到 references/ 里，用到的时候才读。上下文是有限资源，每个 token 都在消耗注意力预算。
6. 流程清晰度：步骤是否可执行？

---

优化原则

• 触发词要具体：不是「帮我」，是「帮我拆一下」「帮我看看这个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