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 才结束。

能力边界说明

✅ 擅长处理

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

⚠️ 需要素材才能做

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

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

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

执行时机

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

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

TRACE 五维度评分标准

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

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

扣分常见原因：

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

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

扣分常见原因：

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

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

扣分常见原因：

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

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

扣分常见原因：

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

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

扣分常见原因：

• 没有新手入门引导，用户不知道从哪里开始
• 输出示例不够真实（用通用模板占位而非真实场景示例）
• 缺乏任何增值特性，只是机械执行指令

评分与修改流程

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 会聚焦该维度打分并给出改进建议。

受众说明

定制化使用指南

可在触发时传入以下参数来定制检查行为：

• 严格模式："严格评测" → 所有子项必须达到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 — 真实评分报告案例（合格/不合格/修改后对比）

使用流程

Step 1: 环境准备

确保开发环境已安装必要的依赖和工具。

Step 2: 配置初始化

根据项目需求进行基础配置。

Step 3: 核心功能使用

按照示例代码实现核心功能。

Step 4: 测试验证

运行测试确保功能正常。

Step 5: 部署上线

完成开发后进行部署和监控。