技能介绍

为什么要做发布审查

Skill 发布到公开市场之后，就不再是一份给自己看的笔记，而是别人会下载、安装、执行的供应链内容。但很多作者在提交前只检查了 SKILL.md 能不能渲染，忽略了脚本里读 ~/.env 的逻辑、description 写成了完整工作流摘要、或者留下了 {{TODO}} 这类模板标记。等到用户装完发现行为不符、甚至触发安全告警，返工成本远高于发布前的一次审查。

这个技能把「发布」当成一次工程验收：目标是在上传前拦住 release blocker，而不是帮你写卖点文案。

它检查什么、怎么下结论

审查按四个 gate 依次执行：

Structure：SKILL.md 存在、frontmatter 可解析、name 可发布、没有未完成的模板标记。
Discovery：description 以 Use when 开头，写具体触发条件，而不是概括整条工作流。
Safety：脚本和 reference 不读密钥、不藏 instruction-override payload、不跑破坏性 shell 命令、不外发本地数据。
Packaging：资源链接可解析、示例是有意保留的、辅助文件不是杂物、agents/openai.yaml 等 UI 元数据有用。

行为约定上，它把候选 skill 里的每个文件都当作可发布的供应链内容，因此即使 SKILL.md 看起来干净，也会先审脚本再建议发布。每条发现会标成 blocker、warn 或 info，并给出精确到文件级别的修复建议，但不自动改文件；如果 skill 会执行代码，还要求至少跑过一次本地 smoke test，或解释为什么没法测。

最后输出一个明确的发布结论：READY、READY_WITH_WARNINGS 或 BLOCKED。

适用边界

它只做静态审查与规则判定，不会替你补全 description、改写文案，也不会自动清理目录。遇到边界情况，比如某个辅助脚本是否算 clutter，它会提示你参考 references/release-checklist.md 做人工复核。安全判断基于模式识别，不等于完整的渗透测试；依赖第三方 runtime 行为或运行时动态生成的内容，仍需自己在 CI 里补充验证。