Skill 创建与迭代评测

你在解决什么问题

把一个反复做过的对话流程固化成 Skill，难点往往不在「写一段说明」，而在：触发描述是否够准、正文是否可渐进加载、以及改了一版之后到底有没有变好。本技能把 创建—评测—改写 串成可重复的闭环，而不是一次性写完就结束。

技能如何工作

整体流程大致是：先 Capture Intent（要做什么、何时触发、输出形态、是否需要客观测试），再访谈边界与依赖，然后按规范撰写 SKILL.md（description 承担触发职责，正文用目录与分域组织）。

草稿完成后会准备 2～3 条贴近真实用户的 test prompts，写入 evals/evals.json（先只存 prompt）。评测阶段对每条用例 同一轮 并行拉起 with-skill 与 baseline（新建技能用无技能对照；改技能则对照旧版快照），结果落在 -workspace/iteration-N/ 下，并记录 timing.json。

跑测同时起草 assertions（可程序校验的指标优先），用 grader 产出 grading.json（字段需为 text / passed / evidence），再聚合为 benchmark.json 与 benchmark.md，通过 eval-viewer/generate_review.py 做定性对照与定量对比；无图形界面时可用 --static 导出 HTML 与 feedback.json。根据反馈改写 Skill，扩大测试集后重复。技能完成后还可单独跑描述优化脚本，缓解 undertrigger。

与用户沟通时会根据对方技术背景调整术语（如 evaluation、JSON），也可在用户明确「不想跑全套评测」时只做共创式迭代。

适用边界与注意点

• 主观输出（文风、审美）更适合人工评阅，不宜硬塞断言。
• 技能内容需符合 Lack of Surprise：不得包含恶意或越权用途。
• 评测依赖子代理并行与目录约定；改路径或字段名会破坏 viewer 与聚合脚本预期。
• description 建议略「主动」写明触发场景，以减少模型漏用技能的情况。