Skill TRACE 质量评测流程

强制规则：每次创建或修改 Skill 后，必须完成本 TRACE 自检，全部子项达到满分标准才算任务完成。 不允许在评分未达标时交付 Skill，也不允许只生成好看的报告而不真正改进 Skill 内容。

⚡ 新手 30 秒入门

这个 Skill 是干什么的？ 帮你检查自己写的 Skill 质量够不够好，哪里不足、怎么改。

什么时候触发？

刚写完一个新 Skill，想知道要不要改 → 直接用
修改了已有 Skill 的核心内容 → 用
用户要求"检查 Skill 质量" → 用

直接复制这些触发示例就能开始：

✅ "帮我检查刚写的 opc-skill 是否符合 TRACE 标准"
✅ "对这个 SKILL.md 做全量 TRACE 自检"
✅ "检查一下 skill-trace-checker 本身的质量有没有问题"
✅ "我修改了招聘 Skill 的 FAQ，重新评测一下"
✅ "这个 Skill 的反模式章节写得够好吗？帮我打分"

一句话流程： 读取 Skill 文件 → 对照20个检查项逐项打分 → 找出 < 5.0 的子项 → 修改 → 重打分 → 全部 5.0 才结束。

能力边界说明

✅ 擅长处理

检查新创建的 Skill：读取 SKILL.md 及 references/ 文件，逐维度打分，输出结构化评分表
定位具体扣分原因：每个低于 5.0 的子项都给出"是什么问题、在哪个文件、怎么改"的精确指引
验证修改是否有效：修改后重新打分，确认实质性改进而非只改措辞
批量检查多个文件：同时对 SKILL.md + references/ 下多份文件综合评判
对比两个版本差异：判断新版本是否比旧版本在某个子项上有实质提升
生成标准评分表：输出统一格式的 TRACE 评分表，方便记录和追踪

⚠️ 需要素材才能做

完整自检：需要提供 SKILL.md 文件路径或完整内容；只凭 Skill 名称无法评测
针对性建议：需要描述 Skill 的使用场景（面向什么用户、解决什么问题），否则只能给通用建议
多版本对比：需要提供两个版本的文件内容，才能判断改进幅度

❌ 超出范围（附替代方案）

帮你写 Skill 内容：本 Skill 只评分，不帮你生成 Skill 内容 → 用 skill-creator 来创建 Skill
评测非 Skill 类文档：如 README、产品文档、代码质量 → 找对应的代码审查工具或文档评审 Skill
执行 Skill 的功能：只负责质量评测，不代替被检查的 Skill 执行实际任务
自动发布或安装 Skill：评测通过后的发布操作需手动完成

执行时机

以下任一情况发生后，立即执行本检查流程：

完成新 Skill 的 SKILL.md 编写
对已有 Skill 进行重大内容修改（新增模块、修改行为规范、调整 FAQ 等）
用户明确要求"检查 Skill 质量"或"TRACE 评测"

TRACE 五维度评分标准

对每个子项按 1.0～5.0 打分，未达 5.0 则必须立即修改 Skill 内容直到满分。

T · Trust 可信任度（目标：5.0）

| 子项 | 满分标准 | 检查方法 | |-----|---------|---------| | 国内适配性 | 全中文界面；支持口语化中文输入；示例基于国内真实场景（微信/淘宝/小红书等） | 检查所有示例和说明是否为中文，触发词是否包含中文关键词 | | 安全性 | 无 P0/P1 安全风险；不引导用户操作他人账号；不处理真实敏感数据 | 检查系统提示词中是否有"禁止行为"章节，是否有隐私保护说明 | | 边界透明度 | 能做/需素材/超范围三类清晰区分，且每类有具体例子 | SKILL.md 中是否有独立的"能力边界说明"章节 | | 数据隐私规范 | FAQ 或专项章节明确说明敏感数据处理原则，提供脱敏操作指导 | 检查是否有隐私/数据安全相关说明 |

扣分常见原因：

示例全是英文场景
没有隐私使用说明
边界描述模糊（只说"有些场景不支持"）

R · Reliability 可靠性（目标：5.0）

| 子项 | 满分标准 | 检查方法 | |-----|---------|---------| | 异常处理 | 所有错误提示为用户语言而非技术报错；格式为"缺少[具体项]+如何补充" | 检查系统提示词中是否有精确错误提示规范，是否明确禁止笼统提示 | | 功能完善性 | 主要使用场景全覆盖，无明显功能盲区；每个功能有输出格式说明 | 数一下功能点，对比典型用户需求是否有遗漏 | | 运行稳定性 | 输入模糊时有明确的降级策略（先给假设版本再问），不挂起也不给空回复 | 系统提示词中是否有"遇到信息不足时"的处理规则 | | 降级兜底 | 超出范围时给出替代工具引导，多任务时按优先级排序 | 能力边界章节是否说明了超范围后的处理方式 |

扣分常见原因：

报错直接抛出技术异常信息（ImportError / File not found）
用户输入不完整时 AI 直接停下来问，没有给假设版本
超范围请求直接拒绝，没有替代方案

A · Adaptability 适用性（目标：5.0）

| 子项 | 满分标准 | 检查方法 | |-----|---------|---------| | 能力边界定义 | 三分类（✅擅长/⚠️需素材/❌超范围）且每类有 3 个以上具体例子 | 检查边界章节的分类数量和例子数量 | | 触发方式精确度 | 每个功能都有"精确触发条件"，包括主触发和子模块路由；用户能判断该用哪个功能 | 检查每个功能模块是否有独立的触发条件说明 | | 受众广度 | 明确说明适用的用户类型，并说明非主要用户（如团队）如何使用 | 检查是否有受众适用说明 | | 定制化支持 | 提供让用户传递个人偏好的机制（如风格卡片、场景参数） | 检查 FAQ 或说明中是否有定制化使用指南 |

扣分常见原因：

触发方式只有关键词列表，没有"什么情况用哪个功能"的判断逻辑
没有说明不同类型用户如何使用

C · Convention 规范性（目标：5.0）

| 子项 | 满分标准 | 检查方法 | |-----|---------|---------| | 渐进式披露 | 至少三层结构（快速入门→功能详情→深度参考），用户可按需深入 | 检查 SKILL.md 是否有快速导航或入门章节，是否有 references/ 深度文档 | | 结构清晰度 | 文件名自解释；SKILL.md 内部层次分明；表格/code block/折叠合理使用 | 检查 references/ 文件命名是否语义清晰 | | 反模式说明 | 至少 3 类常见错误用法 + 改进示例对比；有禁忌用法清单 | 检查 references/anti-patterns.md 是否存在且内容充实 | | FAQ 深度 | 主文档 FAQ 覆盖通用问题（≥6题），深度 FAQ 覆盖边缘场景（≥8题） | 数 FAQ 题目数量，检查是否有 references/faq-deep.md |

扣分常见原因：

只有 SKILL.md，没有 references/ 深度文档
FAQ 只有 3～4 题，覆盖面不够
没有反模式案例，用户不知道什么做法会导致差输出

E · Effectiveness 有效性（目标：5.0）

| 子项 | 满分标准 | 检查方法 | |-----|---------|---------| | 输出准确性 | 系统提示词有"禁止在不确定领域胡编"规则；每个输出注明决策逻辑 | 检查系统提示词中是否有输出准确性约束 | | 内容完整度 | 模块数量×子功能点全面覆盖典型场景；深度 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 文件的实质性改动。

常见问题 FAQ

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 — 真实评分报告案例（合格/不合格/修改后对比）