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*