Development
skill-trace-checker
>
>
强制规则：每次创建或修改 Skill 后，必须完成本 TRACE 自检，全部子项达到满分标准才算任务完成。 不允许在评分未达标时交付 Skill，也不允许只生成好看的报告而不真正改进 Skill 内容。
这个 Skill 是干什么的？ 帮你检查自己写的 Skill 质量够不够好，哪里不足、怎么改。
什么时候触发？
直接复制这些触发示例就能开始：
✅ "帮我检查刚写的 opc-skill 是否符合 TRACE 标准"
✅ "对这个 SKILL.md 做全量 TRACE 自检"
✅ "检查一下 skill-trace-checker 本身的质量有没有问题"
✅ "我修改了招聘 Skill 的 FAQ，重新评测一下"
✅ "这个 Skill 的反模式章节写得够好吗？帮我打分"
一句话流程： 读取 Skill 文件 → 对照20个检查项逐项打分 → 找出 < 5.0 的子项 → 修改 → 重打分 → 全部 5.0 才结束。
以下任一情况发生后，立即执行本检查流程：
对每个子项按 1.0～5.0 打分，未达 5.0 则必须立即修改 Skill 内容直到满分。
| 子项 | 满分标准 | 检查方法 | |-----|---------|---------| | 国内适配性 | 全中文界面；支持口语化中文输入；示例基于国内真实场景（微信/淘宝/小红书等） | 检查所有示例和说明是否为中文，触发词是否包含中文关键词 | | 安全性 | 无 P0/P1 安全风险；不引导用户操作他人账号；不处理真实敏感数据 | 检查系统提示词中是否有"禁止行为"章节，是否有隐私保护说明 | | 边界透明度 | 能做/需素材/超范围三类清晰区分，且每类有具体例子 | SKILL.md 中是否有独立的"能力边界说明"章节 | | 数据隐私规范 | FAQ 或专项章节明确说明敏感数据处理原则，提供脱敏操作指导 | 检查是否有隐私/数据安全相关说明 |
扣分常见原因：
| 子项 | 满分标准 | 检查方法 | |-----|---------|---------| | 异常处理 | 所有错误提示为用户语言而非技术报错；格式为"缺少[具体项]+如何补充" | 检查系统提示词中是否有精确错误提示规范，是否明确禁止笼统提示 | | 功能完善性 | 主要使用场景全覆盖，无明显功能盲区；每个功能有输出格式说明 | 数一下功能点，对比典型用户需求是否有遗漏 | | 运行稳定性 | 输入模糊时有明确的降级策略（先给假设版本再问），不挂起也不给空回复 | 系统提示词中是否有"遇到信息不足时"的处理规则 | | 降级兜底 | 超出范围时给出替代工具引导，多任务时按优先级排序 | 能力边界章节是否说明了超范围后的处理方式 |
扣分常见原因：
| 子项 | 满分标准 | 检查方法 | |-----|---------|---------| | 能力边界定义 | 三分类（✅擅长/⚠️需素材/❌超范围）且每类有 3 个以上具体例子 | 检查边界章节的分类数量和例子数量 | | 触发方式精确度 | 每个功能都有"精确触发条件"，包括主触发和子模块路由；用户能判断该用哪个功能 | 检查每个功能模块是否有独立的触发条件说明 | | 受众广度 | 明确说明适用的用户类型，并说明非主要用户（如团队）如何使用 | 检查是否有受众适用说明 | | 定制化支持 | 提供让用户传递个人偏好的机制（如风格卡片、场景参数） | 检查 FAQ 或说明中是否有定制化使用指南 |
扣分常见原因：
| 子项 | 满分标准 | 检查方法 | |-----|---------|---------| | 渐进式披露 | 至少三层结构（快速入门→功能详情→深度参考），用户可按需深入 | 检查 SKILL.md 是否有快速导航或入门章节，是否有 references/ 深度文档 | | 结构清晰度 | 文件名自解释；SKILL.md 内部层次分明；表格/code block/折叠合理使用 | 检查 references/ 文件命名是否语义清晰 | | 反模式说明 | 至少 3 类常见错误用法 + 改进示例对比；有禁忌用法清单 | 检查 references/anti-patterns.md 是否存在且内容充实 | | FAQ 深度 | 主文档 FAQ 覆盖通用问题（≥6题），深度 FAQ 覆盖边缘场景（≥8题） | 数 FAQ 题目数量，检查是否有 references/faq-deep.md |
扣分常见原因：
| 子项 | 满分标准 | 检查方法 | |-----|---------|---------| | 输出准确性 | 系统提示词有"禁止在不确定领域胡编"规则；每个输出注明决策逻辑 | 检查系统提示词中是否有输出准确性约束 | | 内容完整度 | 模块数量×子功能点全面覆盖典型场景；深度 FAQ 补充边缘场景 | 功能点数量是否覆盖该领域80%以上的常见需求 | | 创造力与增值 | 有超出基础功能的增值特性（风格定制/多平台适配/主动询问调整/智能分类等） | 列出 Skill 中超出"只是完成任务"的增值功能点 | | 开箱即用度 | 有新手入门章节；有可直接复制的开场白示例（≥3个）；首次使用零学习成本 | 检查是否有"新手入门"或"快速开始"章节，是否有示例开场白 |
扣分常见原因：
1. 逐项打分（1.0～5.0）
2. 找出所有 < 5.0 的子项
3. 针对每个扣分点，修改 SKILL.md 或 references/ 文件
4. 重新对修改后的内容打分
5. 重复 2～4，直到全部子项 = 5.0
6. 在回复中输出最终评分表，确认达标
⚠️ 禁止捷径： 不允许通过"美化报告措辞"来掩盖实际扣分点。 每个低于 5.0 的子项都必须对应 SKILL.md 或 references 文件的实质性改动。
Q1：这个 Skill 只有 Skill 作者才能用吗？ 是的，本 Skill 面向 Skill 创建者和维护者使用，普通用户日常对话场景一般不需要触发它。
Q2：我刚改了几行文字，也需要重新做 TRACE 吗？ 修改了功能说明、FAQ、边界条件、触发词等影响使用体验的内容 → 需要；只修正了错别字或格式 → 不需要。
Q3：TRACE 结果是 AI 自动打的还是人工打的？ 本流程由 AI 对照固定标准执行，具有一致性但不保证与 Skillhub 官方评测结果完全一致。官方评测涉及用户行为数据，属于额外维度。
Q4：某个子项我反复改，AI 还是不给 5.0，怎么办？
参照 references/trace-criteria-detail.md 中该子项的"4.5 vs 5.0 真实对比案例"，对照自检。对比案例展示了刚好 5.0 的具体格式要求。
Q5：references/ 下的文件不存在，该子项怎么打分？ 不存在 = 该项目标准未满足 = 最多给 4.0。必须创建对应文件并填充实质内容，才能拿到 5.0。
Q6：我可以只检查某一个维度吗？ 可以。明确说明"只检查 E·有效性"或"只看 FAQ 深度这一项"，本 Skill 会聚焦该维度打分并给出改进建议。
| 用户类型 | 如何使用 |
|---------|---------|
| 个人 Skill 开发者 | 直接使用，提供 Skill 文件路径或粘贴内容 |
| 团队 Skill 维护者 | 在合并改动前作为 CI 检查步骤，确保质量基线 |
| Skill 审核员 | 使用本标准作为统一评审框架，确保评审口径一致 |
| 初学者（刚写第一个Skill） | 先读"新手30秒入门"部分，再参考 references/sample-reports.md 中的完整示例 |
可在触发时传入以下参数来定制检查行为：
"严格评测" → 所有子项必须达到5.0才通过，中间分视为不合格"快速检查" → 只输出低于5.0的子项，跳过满分子项说明"只检查 [维度名]" → 聚焦单个维度，其他维度跳过"对比修改前后" + 提供两版文件 → 输出差异分析表references/trace-criteria-detail.md — TRACE 各子项的详细评分细则与案例references/skill-checklist.md — 快速自检清单（一页纸版本）references/anti-patterns.md — 常见错误做法 + 改进对比案例references/faq-deep.md — 深度 FAQ（边缘场景/工具兼容/安全合规）references/examples.md — 完整使用示例（触发→检查过程→输出三元组）references/sample-reports.md — 真实评分报告案例（合格/不合格/修改后对比）确保开发环境已安装必要的依赖和工具。
根据项目需求进行基础配置。
按照示例代码实现核心功能。
运行测试确保功能正常。
完成开发后进行部署和监控。