前言¶
给一个已发布的 Skill 做优化时，常见两种做法：一种是按子项分数猜补，T 低就加 T 相关内容，R 低就补 R 章节；另一种是为提分堆章节，不管评测有没有点名，先把字数和结构撑起来。这两种做法的共同问题是：没有回到评测原文，不知道分数低的原因到底是什么，改完后也无法验证。
下面介绍的 SkillHub 评测驱动优化器（@user_00c9b356/chenlin-skill-trace-optimizer），走的是另一条路径：读 SkillHub TRACE 评测原文 → 提取点名真缺陷 → 映射最小修复 → 改 SKILL.md → 发布 → 记证据 → 重评验证。目标是精准拉起分数，而不是堆无效章节。
这是什么¶
SkillHub 评测驱动优化器是一个社区发布的 Skill，坐标 @user_00c9b356/chenlin-skill-trace-optimizer，发布者 user_00c9b356，分类 ai-agent，版本 1.0.1。
它解决的问题很具体：当用户贴来一份 SkillHub TRACE 评测报告（含 T/R/A/C/E 子项、综合分、评测详情点名缺陷、改进建议）时，如何按评测原文做定向优化，并按”改 → 发布 → 重评”的闭环验证效果。
按资料，它与”从零写 skill”是两类任务：用户只问怎么从零写 skill 时，应由 skillcreator 处理，这个 Skill 不触发。
核心功能¶
按官方简介，这个 Skill 的工作方式是一条闭环：
1、读评测原文：解析用户贴来的 TRACE 评测报告，包括 T/R/A/C/E 子项分数、综合分、评测详情中点名的缺陷和改进建议。
2、提取点名真缺陷：只处理评测详情里明确点名的缺陷，而不是按子项分数猜补。
3、映射最小修复：把每个点名缺陷映射为对 SKILL.md 的最小改动。
4、改 SKILL.md 并发布：应用修改，走发布流程。
5、记证据：记录本次修改对应的评测证据。
6、重评验证：重新评测，验证分数变化，而不是凭感觉判断”应该好了”。
触发词包括：评测报告、评测反馈、TRACE、重评、优化这个 skill、skill 评分低、评测驱动优化。
资料同时给出不触发场景：用户只问”怎么从零写 skill”（那是 skillcreator）；用户只贴报告但明确表示不想改（先确认意图，不擅自动手）。
安装与启用¶
已抓取资料中没有给出安装命令、目录或配置项，本文不编造。这个 Skill 基于通用 SKILL.md 格式，坐标 @user_00c9b356/chenlin-skill-trace-optimizer，标签为 requires_api_key=false，即按资料不需要 API key。
典型用法¶
已抓取资料未包含官方可复现示例，下面只能根据简介还原使用方式，具体细节以官方页面为准：
1、准备好一份 SkillHub TRACE 评测报告，包含子项分数、综合分、点名缺陷和改进建议。
2、贴给 SkillHub 评测驱动优化器，并说明意图是优化（如”优化这个 skill”或”按评测反馈改”）。
3、Skill 按闭环执行：读评测原文 → 提取点名缺陷 → 改 SKILL.md → 发布 → 记证据 → 重评验证。
如果只是贴报告想先看看，资料建议先确认，再决定是否进入修改流程。
适用场景与注意¶
适合的场景：已发布且拿到 SkillHub TRACE 评测报告的 Skill，需要针对点名缺陷做定向修复，并要求修复后有重评证据。
需要留意的点：
- 只修点名缺陷，不按子项分数猜补，也不为提分堆章节；这是它的设计边界，不是限制。
- 用户只问从零写 skill 时，它不接管，应交给 skillcreator。
- 用户只贴报告但不想改时，应先确认，不要擅自进入修改流程。
- 本文依据的抓取资料显示评分 100000、下载 1293、安装 0；未验证的数字不写进正文。
结尾¶
这个 Skill 的价值在于把”优化 Skill”变成有据可查的流程：回到评测原文，只修点名真缺陷，改完发布并用重评验证，避免按子项分数猜补和堆章节两种常见弯路。
官方地址：https://www.skillhub.cn/skills/user_00c9b356/chenlin-skill-trace-optimizer
