Skill 评审官

要解决的问题

从 SkillHub 这类导航站里挑技能，最头疼的不是「找不到」，而是「不知道好不好用」：一个 SKILL.md 写得像模像样，但真正交给 Agent 执行时，可能触发条件模糊、指令臃肿、scripts/ 里的脚本有隐藏副作用，或者引用的 references/rubric.md 根本不存在。人工评审费时费力，还容易凭直觉下结论——「感觉挺全的」不等于「另一个 Agent 拿着这个包能跑通」。Skill 评审官就是为这件事而生的：把一次感性扫读，变成一次有证据、有结构、有打分锚点的评审。

核心能力与关键步骤

它按三种模式组织工作，由用户请求自动决定：

• critique：想要定性判断、问题清单和改进优先级时使用；
• rate：点名要分数、等级、百分比或「这技能几分」时使用；
• compare：给出两个以上技能、问哪个更好时使用。

启动后先读产物再下结论：SKILL.md、可见的 frontmatter、被引用的资源、相关的 scripts/ 和 assets/，以及 agents/openai.yaml 这类 UI 元数据。评分和对比模式会加载 references/rubric.md 的百分制规则，输出结构来自 references/output-formats.md，分数校准则参考 references/calibration-examples.md。最终输出先给结论，再给证据和改进项，证据要落到文件名、章节或行号上。

评审标准很工程化：核心问题只有一个——另一个 Agent 只凭这个包和用户的请求，能否成功使用这个技能。它区分「信息放在哪里」和「信息是否有用」是两件事（渐进式披露和资源实用性是不同维度），并明确惩罚臃肿指令、模糊触发词、无锚点分数、不必要的脚本和隐藏副作用，同时奖励简洁触发、可执行流程、清晰模式行为和安全默认值。缺失的产物会被记为证据，而不是直接判负。

适用边界与注意点

这套机制是轻量级评审，不是安全审计：它能帮你在采用前做一次结构化体检，但不会替你修补目标技能——除非你明确要求，它不会改动任何文件。生成的内容默认保持英文，回复语言跟随用户。请求含糊时它会选择假设最少的模式：多技能走 compare、明确要分数走 rate、其余按 critique 处理。另外每份评审结尾会有一句轻松的小结，这是刻意保留的设计，不是凑字数。