技能审查员

这个技能要解决的问题

当 skill 越来越多，质量参差不齐就成了现实问题：有的 SKILL.md 引用了不存在的脚本，有的文档成了没人链接到的孤立文件，有的指令在 Agent 实际使用时根本走不通。人工 review 这类问题时很容易带着「作者视角」的滤镜，漏掉那些只有真正使用者才会撞上的坑。skill-reviewer 的核心思路是换位：始终以「第一次拿到这个 skill、要完全依靠它完成任务的 Agent」的身份去读它。凡是这个视角下读不懂、走不通、会被误导的地方，都算问题。

核心能力与工作流程

整个审查分五步推进：

• Step 1 确认目标：从用户给出的目录或 SKILL.md 路径向上/向内定位根目录；找不到 SKILL.md 就直接告知并请用户确认，不猜测继续。同时根据对话历史判断当前是否正在构建该 skill，决定是否启用检查项 2.12 的「对话约束沉淀」子项。
• Step 2 盘点文件与引用图：递归列出全部文件（排除 .git/、__pycache__/、node_modules/、虚拟环境目录），从 SKILL.md 出发沿 markdown 链接、路径引用、脚本 import 做多跳可达性分析，得到可达文件集与孤立文件集。文件数超过 20 时，可拆成若干分支并行派发子代理，主会话保留跨文件冲突、孤立文档、版本管理、结构一致性等需要全局视野的检查项，最后合并去重。
• Step 3 按清单审查：执行 references/review-checklist.md 中机械层校验（1.1–1.4）与通用检查（2.1–2.16）；仅当被审 skill 包含需安装的工具/脚本、第三方依赖或登录流程时，才执行依赖与安装检查（3.1–3.4）。每条问题必须落到位置（文件:行）+ 问题描述 + 建议修改，不接受「感觉不好」式的模糊反馈；标记「需用户判决」的检查项先收集暂存，不逐条打断。
• Step 4 输出报告：按 references/report-template.md 输出 P0（必须修复）→ P1（应当修复）→ P2（建议考虑）分级报告，再将暂存的判决项集中逐类提问。只要求 review 时报告即为交付物，动手修改要等用户明确要求。
• Step 5 可选深度模式：默认不启用。审查完成后询问一次，可单选或都选「增强 Review」（联网对照领域现状）或「实测验证」（触发率正负样本抽测、行为压力测试、meta 反馈）。

适用边界

它不是构建工具：从零创建或重构 skill 不在其职责内，那是构建类技能的事。审查质量高度依赖 references/ 下的清单与模板文件是否完整；深度模式需要联网或可运行的实测环境，按需选择。另外，本 skill 版本由 git tag 管理，跟进更新时留意 tag 对应关系。