源项目： mattpocock/skills

被评测 Skill： writing-great-skills / SKILL.md

项目作者： Matt Pocock

评测对象定位： 一个用于指导如何编写高质量 Agent Skill 的参考型 Skill。它的 description 明确指向如何写好和编辑 Skill，目标是让 Skill 更 predictable，也就是更可预测。

writing-great-skills 的核心不是写更长提示词，而是把 Agent 行为压成可预测流程。

Skill 的目标不是让 Agent 知道更多，而是让 Agent 每次都按更可靠的路径做事。

一句话结论

writing-great-skills 不是一个强执行型 Skill，而是一套关于如何设计 Skill 的方法论。

它最有价值的地方，不是告诉你怎么写更长的提示词，而是提醒我们：

Skill 的核心价值，是把随机系统里的 Agent 行为，尽可能压成稳定、可复用、可评估的流程。

很多人做 Skill，容易把它理解成「Prompt 模板」「知识片段」「操作说明」。但这个 Skill 讲的是更底层的问题：

  • 一个 Skill 应该什么时候被调用？
  • 什么内容应该写进 SKILL.md？
  • 什么内容应该外置？
  • 如何减少上下文浪费？
  • 如何避免 Agent 提前完成？
  • 如何用更少的词，让模型更稳定地进入某种工作模式？

所以，它不是一个普通 Skill，而更像是 Skill 设计的「宪法」。

一、基础评分

评测维度评分判断
作为 Skill 设计方法论8.8 / 10框架清晰，概念密度高，适合高级 Skill 设计
作为直接可执行 Skill6.8 / 10思想很强，但缺少明确流程、输出格式和验证机制
对 Agent Skill 工程体系的参考价值8.5 / 10很适合作为 Skill 评审规范的底层参考

它最大的价值不是「拿来即用」，而是提供了一套判断标准。

如果你正在构建 Agent 产品、Skill 系统、插件体系或者自动化工作流，这个 Skill 值得认真学习。

二、它最核心的判断：Skill 是为了压缩随机性

这个 Skill 开头有一个很强的定义：

Skill 的存在，是为了从随机系统中榨出确定性。

更准确地说，它强调的不是输出结果完全一致，而是 Agent 每次都能走相同的过程。它把这种能力称为 Skill 的根本美德：Predictability。

这个判断非常关键。

因为 Agent 的天然状态是不稳定的。同一个任务，今天它可能先读文件，明天它可能先总结，后天它可能跳过关键检查。结果看起来都像完成了，但过程并不稳定。

而 Skill 的真正价值，就是把这种不稳定压成流程：

不是让 Agent “知道更多”，
而是让 Agent “每次都按更可靠的路径做事”。

这也是 Skill 和普通 Prompt 最大的区别。

Prompt 更像一次性指令。

Skill 更像可复用的行为协议。

三、调用方式不是小事：Model-invoked vs User-invoked

writing-great-skills 把 Skill 分成两类：

类型适合场景代价
Model-invoked Skill希望 Agent 自动识别并调用description 常驻上下文，增加 context load
User-invoked Skill只希望用户手动触发不占上下文，但增加人的 cognitive load

如果一个 Skill 需要 Agent 自己判断什么时候使用，或者需要被其他 Skill 调用，就应该让它 model-invoked。

反过来，如果这个 Skill 只会被用户手动触发，就应该设置为 user-invoked，避免无意义地占用上下文。

它自己也设置了 disable-model-invocation: true，说明作者把它定位为人工主动触发的参考型 Skill，而不是自动触发型 Skill。

这背后其实是一个非常产品化的判断：

Skill 不是越多越好，自动触发也不是越多越好。

每一个自动触发型 Skill，都会占用 Agent 的注意力和上下文预算。

每一个手动触发型 Skill，则会占用用户的记忆负担。

所以 Skill 系统真正要管理的，不只是功能，而是两种负载：

负载含义典型问题
Context Load模型每轮都要看到的内容description 太多，Agent 选择混乱
Cognitive Load用户必须记住的内容Skill 太多，用户不知道该用哪个

这个 Skill 还提出一个很好的解决思路：当 user-invoked Skill 多到用户记不住时，可以用一个 router skill 作为索引，让用户只记住一个入口。

这对 Agent 产品设计很有启发。

未来 Skill 系统不应该只是一个文件夹，而应该有三层：

Skill Registry：有哪些 Skill
Skill Router：什么时候用哪个 Skill
Skill Runtime：调用后如何稳定执行

四、最值得吸收的框架：信息分层

writing-great-skills 里最专业的部分，是它对 Skill 内容的分层。

它把 Skill 内容分成三类：

层级内容作用
In-skill step直接写在 SKILL.md 里的步骤Agent 必须立即执行的动作
In-skill reference写在 SKILL.md 里的规则、定义、标准Agent 执行时需要随时参考
External reference放到外部文件里的资料只在特定分支需要时再读取

它强调，SKILL.md 里的 step 应该是有顺序的动作，每一步都要有 completion criterion，也就是完成标准。

reference 是定义、规则或事实。

external reference 则应该放在独立文件中，只在需要时再读取。

这个框架解决了一个非常常见的问题：很多 Skill 会越写越长，最后变成一个大杂烩。

有步骤，有背景，有规范，有例子，有注意事项，有反例，有历史经验。结果是 Agent 真正执行任务时，不知道哪些是必须做的，哪些只是参考。

这个 Skill 给出的原则可以总结成一句话：

SKILL.md 不应该是知识库，而应该是执行入口和导航层。

也就是说，最核心的步骤应该留在主文件里；只有部分场景才需要的参考资料，应该通过外部文件渐进披露。

一个好的 Skill，不是把所有东西都塞进主文件，而是要区分：

Agent 现在必须知道什么？
Agent 需要时再知道什么？
Agent 永远不该在主流程里看到什么？

五、完成标准：防止 Agent “看起来做完了”

这个 Skill 还有一个非常关键的概念：completion criterion，完成标准。

它强调，每一个步骤都应该以一个可检查的完成条件结束。这个完成条件最好是明确、可验证、可穷尽的。

比如不要写「生成一个修改清单」，而要写：

每一个被修改的模型都必须被纳入清单。

这个点非常实用。

因为 Agent 最常见的问题，不是完全不会做，而是：

做到一半，就认为自己已经完成了。

这也是它在 Failure Modes 里提到的 Premature completion，也就是提前完成。它建议优先通过更清晰的完成标准来解决；如果还不够，再考虑把后续步骤隐藏或拆分，避免 Agent 被后面的任务吸引，导致当前步骤做得不够深入。

这对长任务特别关键。

如果我们希望 Agent 做代码审查、研究报告、竞品分析、数据清洗、合同审查，就不能只写：

请仔细检查。
请深入分析。
请全面总结。

这些都是弱指令。

更好的写法是：

检查每一个 API 端点是否存在权限校验。

完成标准：
所有新增和修改的接口都被逐一列出，
并标注是否存在鉴权、参数校验和异常处理。

Skill 的专业化，往往不是靠更华丽的语言，而是靠更可验证的完成条件。

六、Leading Word：用一个词压缩复杂行为

这个 Skill 里还有一个很高级的概念：Leading Word。

它指的是一个模型预训练中已经有较强语义结构的词，可以用来压缩复杂行为。

例如 lesson、fog of war、tracer bullets 这类词，可以比一长串解释更有效地唤起模型的既有认知。

这个思想很有价值。

很多 Skill 写得很啰嗦，是因为它不断重复解释同一个行为：

快速、低成本、反馈短、持续迭代、尽快验证。

但如果模型已经理解 tight loop，就可以用一个强语义词压缩整个行为区域：

Use a tight loop.

这有两个好处：

  1. 节省 token
  2. 提升行为稳定性

因为一个好的 Leading Word，不只是缩写，它是一个行为锚点。

这对 Skill 命名、Agent 模式命名、流程命名都很重要。

未来高质量 Agent 产品里，很多核心能力可能不是靠长提示词驱动，而是靠一组稳定的工作词汇驱动。

Leading Word可能唤起的行为
tight loop快速反馈、短周期验证
red team反方审查、攻击性测试
tracer bullet先打通最小可运行链路
postmortem失败复盘、根因分析
operating memo结构化决策备忘录

好的 Skill，不只是写步骤，也是在建立 Agent 的工作语言。

七、它的主要缺点：理念强，执行弱

这个 Skill 最大的问题是：它更像一篇高密度方法论文档，而不是一个可直接运行的工作流。

如果我让 Agent 使用它来评审另一个 Skill，它没有给出明确流程：

第一步评审什么？
第二步检查什么？
最后输出什么格式？
评分标准是什么？
是否要给出改写版本？
是否要给出测试用例？

所以它对高级用户非常有价值，但对普通用户不够直接。

它告诉你什么是好 Skill，但没有把自己包装成一个强执行的 Skill Reviewer。

这也是我为什么给它两个分数：

  • 作为方法论：高分
  • 作为执行型 Skill：中高分，但不算完整

八、建议一：保留为 Skill 设计原则

第一个改造方向，是把它保留为参考型 Skill，可以叫：

skill-design-principles

它的定位是 Skill 设计原则。

主要保留这几个概念：

  • Predictability
  • Invocation
  • Context Load
  • Cognitive Load
  • Information Hierarchy
  • Completion Criterion
  • Progressive Disclosure
  • Leading Word
  • Pruning
  • Failure Modes

它不负责直接输出结果，而是作为 Skill 设计的基础语言和评审准则。

这种 Skill 适合 user-invoked，不需要常驻上下文。

因为它不是每个任务都需要，只在设计、评审、重构 Skill 时使用。

九、建议二：改造成 Skill Reviewer

第二个改造方向，是把它变成执行型 Skill，可以叫：

skill-reviewer

它的定位是直接评审和改写一个 Skill。

它应该有固定流程：

---
name: skill-reviewer
description: Review and improve Agent Skills for predictable execution, correct invocation, lean context usage, clear completion criteria, and production readiness.
---

Review the provided Skill using this process:

1. Identify the intended user, task, and invocation mode.
   Completion criterion: decide whether it should be model-invoked, user-invoked, or reference-only.

2. Review the description.
   Completion criterion: every trigger maps to a distinct branch; duplicated synonyms are removed; leading words appear early.

3. Review the information hierarchy.
   Completion criterion: separate steps, in-skill reference, and external reference; move branch-specific material out of SKILL.md.

4. Review every step.
   Completion criterion: each step has a checkable and exhaustive completion criterion.

5. Diagnose failure modes.
   Completion criterion: list any premature completion, duplication, sediment, sprawl, or no-op.

6. Produce a revised SKILL.md.
   Completion criterion: output a cleaner version ready to use.

这样它才从「方法论」变成「生产工具」。

十、建议三：加入 Eval 机制

如果进一步工程化，还应该增加 Skill Eval。

因为一个 Skill 写得好看，不代表它真的有效。

至少要测试两件事：

测试项问题
Invocation Eval该调用时，Agent 是否真的会调用？不该调用时，是否不会误触发？
Execution Eval调用后，Agent 是否真的按预期流程完成任务？

一个生产级 Skill，不应该只看文档质量，还应该看行为结果。

可以设计一组测试任务：

Case 1：用户明确要求评审 Skill，Agent 是否调用 skill-reviewer？
Case 2：用户只是普通写作请求，Agent 是否避免误触发？
Case 3：给一个过长 Skill，Agent 是否能识别 sprawl？
Case 4：给一个缺少完成标准的 Skill，Agent 是否能补上 completion criterion？
Case 5：给一个 description 触发范围过宽的 Skill，Agent 是否能收窄？

这才是 Skill 从「写得不错」走向「可生产化」的关键。

十一、对 Agent 产品的启发

这个 Skill 最值得带走的一句话是：

Skill 不是 Prompt 收藏夹，而是 Agent 行为稳定器。

它提醒我们，Agent 产品的真正难点，不只是接入更多模型、更多工具、更多插件，而是如何让 Agent 的行为稳定下来。

未来 Skill 系统至少需要四层能力：

1. Skill Authoring：如何写 Skill
2. Skill Routing：什么时候调用哪个 Skill
3. Skill Runtime：调用后如何稳定执行
4. Skill Eval：如何证明 Skill 真的有效

如果没有这四层，Skill 生态很容易变成一堆 Prompt 文件。

看起来很多，实际不可控。

看起来很强，真实执行不稳定。

看起来复用，最后每次都要人工兜底。

而高质量 Skill 的目标，应该是降低 Agent 的行为方差。

十二、最终结论

writing-great-skills 是一个非常值得学习的 Skill。

它的价值不在于直接帮你完成某个任务，而在于它提出了一套高质量 Skill 设计语言：

  • Skill 要服务于 predictability
  • 自动调用和手动调用要根据负载权衡
  • SKILL.md 要区分步骤、参考和外部资料
  • 每一步都要有可检查的完成标准
  • Skill 要定期 pruning，避免沉积、膨胀和无效指令
  • 好的 leading word 可以用更少 token 稳定更多行为

它的不足也很明显：

它更像方法论，不像执行器；更像设计原则，不像评审流程。

所以最好的使用方式，不是直接照搬，而是把它变成一套 Skill 工程规范：

Skill Design Principles
        ↓
Skill Reviewer
        ↓
Skill Rewriter
        ↓
Skill Eval
        ↓
Skill Registry / Router

这才是它真正的产品化方向。

从这个角度看，writing-great-skills 给出的不是一个 Skill，而是一个信号：

Agent 进入生产环境后，真正稀缺的不是会写 Prompt 的人，而是能把 Agent 行为压成稳定流程的人。

这也是 Skill 工程接下来最值得关注的方向。

参考来源