vikynofebriputra-creator skill-static-review
何时使用
- 用户提供一个 skill 的说明文件、目录结构、脚本清单或完整包内容，希望判断它是否适合发布或进入动态评估。
- 用户要求检查 skill 是否存在结构混乱、边界不清、步骤不可执行、依赖不明、输出不可验证等问题。
- 用户希望得到一份可操作的质量评审报告，而不是泛泛评价。
不要用于：
- 实际运行 skill、执行动态 benchmark 或调用外部 verifier。
- 评审普通提示词、Agent 工作流或产品 PRD，除非用户明确要求按 skill 包标准做静态检查。
- 替用户直接重写整个 skill；本技能只输出审核结论和修改建议。
如何调用
- 收集待评审材料：至少需要 skill 的主说明文件；若有脚本、资源文件、目录树、示例输入输出，也一并读取。
- 识别 skill 的单一职责：判断它的目标领域、任务族、适用边界和反例边界是否清楚。
- 检查结构与规模：统计模块 / 文件数量，判断是否过度集中或过度拆分；确认是否包含使用条件、操作步骤、边界、示例、依赖说明。
- 检查程序化质量：逐步判断每个步骤是否原子化、可执行、具备前置 / 后置条件、失败路径和观察 → 决策准则；标记退化为事实性知识或宣传文案的部分。
- 检查验证器对齐：确认是否声明面向的 verifier 类型、输出格式是否能被稳定比对、是否暴露中间检查点。
- 检查来源与可信度：确认来源标签、版本 / 作者 / 更新时间、底层工具或 API 兼容说明是否存在；对 self-generated 或来源不明的内容提高风险等级。
- 检查 Agent 兼容性：按常见调用风格评估兼容性，例如 ReAct、代码生成型 Agent、CLI 型 Agent；说明最小模型能力和运行时依赖。
- 输出分级结论：给出通过 / 有条件通过 / 不建议发布，并按严重程度列出问题和改进动作。
返回格式
向用户返回一份结构化评审报告，包含：
{
"overall_result": "通过 | 有条件通过 | 不建议发布",
"score": {
"structure_and_size": "0-5",
"coverage_boundary": "0-5",
"procedural_quality": "0-5",
"verifier_alignment": "0-5",
"source_credibility": "0-5",
"agent_compatibility": "0-5"
},
"summary": "一句话总结主要质量状态",
"blocking_issues": [
{
"area": "问题所属维度",
"evidence": "来自材料的证据",
"impact": "为什么会影响使用或动态评估",
"fix": "必须修改的动作"
}
],
"improvement_suggestions": [
{
"priority": "高 | 中 | 低",
"suggestion": "具体建议",
"expected_effect": "修改后的收益"
}
],
"compatibility_matrix": [
{
"agent_type": "ReAct | code-gen | CLI | other",
"compatibility": "兼容 | 需改写 | 不兼容",
"notes": "原因"
}
],
"release_gate": {
"can_enter_dynamic_eval": true,
"required_before_release": ["发布前必须补齐的事项"]
}
}
如果材料不足，应明确列出缺失项，并只基于已提供材料给出临时结论。
外部依赖
- 无必需外部依赖。
- 若用户提供的是文件路径或目录，需要当前会话具备读取这些文件的权限。
- 若用户要求核查远程仓库、论文或网页来源，需要网络访问；网络不可用时只做本地材料评审。
限制与已知问题
- 静态评审不能证明 skill 真实有效，只能判断其是否具备进入动态测试的基本质量。
- 无法替代 deterministic verifier、单元测试、状态差异测试或真实任务轨迹评估。
- 对脚本正确性只能做结构与接口层面的审查；除非用户另行要求运行测试，否则不执行代码。
- 当材料只有摘要、截图或片段时，结论必须标注为低置信度。
- 对来源不明或自生成的 skill，应默认提示需要更强的测试证据。
完整示例
示例 1：评审一个待发布 skill
输入：
请评审这个 skill 是否达到发布标准。材料包括 SKILL.md、scripts/run.py 和 examples/。
输出要点：
结论：有条件通过。
主要问题：
1. 输出格式没有稳定 schema，动态评估时难以自动比对。
2. 依赖中使用了第三方 API，但没有说明 API key 获取方式和失败行为。
3. 步骤 3 同时包含抓取、清洗和总结，粒度过粗。
建议：
- 增加固定 JSON 输出格式，并保持成功 / 失败字段一致。
- 补充依赖说明和缺失凭据时的返回格式。
- 将步骤拆成抓取、解析、校验、汇总四个动作。
示例 2：材料不足时
输入：
这是一个 skill 的简介，帮我看质量。
输出要点：
临时结论：无法完整判断，不建议直接发布。
缺失材料：
- 主说明文件全文
- 文件 / 模块清单
- 输入输出示例
- 依赖说明
- verifier 对齐说明
基于现有简介可见的风险：
- 适用边界不清，可能被错误调用。
- 没有看到可执行步骤，可能只是普通提示词说明。