full-stack-skills 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— 真实评分报告案例（合格/不合格/修改后对比）
使用流程
Step 1: 环境准备
确保开发环境已安装必要的依赖和工具。
Step 2: 配置初始化
根据项目需求进行基础配置。
Step 3: 核心功能使用
按照示例代码实现核心功能。
Step 4: 测试验证
运行测试确保功能正常。
Step 5: 部署上线
完成开发后进行部署和监控。