技能锻造工厂

解决什么问题

写 SKILL.md 时，最容易把「人类读得懂」误当成「Agent 会执行」。一行指令是否真的改变了模型行为，还是只是一个 no-op；某个 leading word 是否强到能稳定触发；流程会在哪里发生 premature completion——这些判断无法靠反复阅读草稿得出，只能靠运行证据裁决。

它如何工作

整套流程遵循一句话：静态 critique 负责提出假设，实际运行负责判决。

• Step 0 选择 invocation：在写内容前先决定技能如何被触达；模型自动调用付出的是长期 context load，用户手动调用付出的是人的 cognitive load，完成时要明确说出这次付的是哪一份代价。
• Step 1 捕获意图并枚举 branches：从当前对话中挖掘工具、步骤顺序、用户纠正、输入输出格式，再访谈边界情况；把每一种真实调用方式列成 branches，并找出用户实际会说出 的触发词。
• Step 2 沿信息阶梯起草：正文放可按顺序执行的步骤，每步结束于可检查的完成标准；reference 按分支需要就近放置或用 context pointer 显式披露；用重复出现的 leading word 锚定行为，而不是堆同义词。
• Step 3 修剪并提出假设：逐行做 no-op 测试、去重、相关性检查和 sprawl 控制；此步只能提名嫌疑，不能定罪。
• Step 4 运行裁决：用测试提示在 evals/evals.json 中生成 with-skill 与 baseline 运行，再按 transcript、重复运行方差、触发率分别给假设下结论。
• Step 5 按失败模式修补：premature completion 先收紧完成标准；thin legwork 提高要求或换更强的 leading word；no-op 删除或替换；mis-triggering 改 description 措辞；过拟合测试用例则要泛化解释。
• Step 6 调触发并交付：用 scripts/run_loop.py 跑应当/不应当触发的查询集，最终按平台决定交付普通文件夹还是 .skill 包。

适用边界

这套方法不是通用 QA。每个测量指标都在裁决一个具体设计判断，而不是笼统地给质量打分。平台能力会影响可用仪器：Claude Code 与部分可脚本化 CLI 才能跑完整 harness；没有子代理或可脚本化 CLI 时，应降级为逐个提示自测并阅读自己的 transcript，仪器变弱但 verdict 标准不变。另外，这套工具链是内置的固定副本，上游改进不会自动同步，需要显式维护。