skill-creator 介绍

---

第一章：直觉锚定 ── 「你就是那个菜谱编辑长」想象你是一家大型连锁餐厅的菜谱编辑长。

厨师们（Claude）天赋异禀，但每家分店的招牌菜做法各异、没有书面记录。你的工作是：

1. 采访厨师，把他们藏在脑子里的手艺 写成标准菜谱（SKILL.md）
2. 找几个试吃员，测试菜谱是否能复现同样的味道（eval 评测）
3. 根据反馈反复修订，直到任何一位厨师按照菜谱都能做出一样的效果
4. 最后把菜谱装订成册，分发给所有分店（package & install）

skill-creator 就是这位编辑长的工作手册：它告诉 Claude 如何把一段隐性工作流，沉淀成可复用、可测试、可迭代的 Skill。

---

第二章：概念骨架 ── 看清 Skill 的完整结构

2.1 一个 Skill 的物理构成

2.2 三级加载机制（信息按需展开）

💡 设计哲学：三级结构确保常驻内存的只有"门牌号"，详细地图只在真正需要时才展开——节省 context window，也让 Skill 保持专注。

---

第三章：机制拆解 ── skill-creator 的完整运转流程

逐步说明

Step 1 · 捕捉意图
询问「这个 Skill 让 Claude 能做什么 / 什么时候触发 / 输出什么格式」。
🤔 这一步的目的是：把模糊的需求转化为可写代码的规格书，避免写完才发现方向偏了。

---

Step 2 · 深度采访 + 撰写 SKILL.md
主动追问边界条件、依赖工具、异常处理；同步研究可参考的现有 Skill。
🤔 这一步的目的是：在写作前建立完整的信息模型，description 要"稍微强势一点"以对抗 Claude 的 undertrigger 倾向。

---

Step 3 · 设计测试用例
选取「有一定复杂度、真正需要 Skill 参与」的真实 Prompt，而非「读一个文件」这种 Claude 自己就能完成的简单任务。
🤔 这一步的目的是：测试用例的质量直接决定迭代方向是否正确。

---

Step 4 · 执行测试 & 生成评测报告
在 Claude Code 中用子 Agent 并行运行；在 Claude.ai 中串行自执行并把结果直接呈现在对话里。
🤔 这一步的目的是：让人类在"看到实际输出"之后再给反馈，而不是对着文档空想。

---

Step 5 · 迭代改写
基于定性反馈（用户主观评价）+ 定量断言（通过/失败的检查点）双轨修订 SKILL.md。
🤔 这一步的目的是：每次迭代都有明确的改进信号，避免盲目猜测。

---

Step 6 · description 触发率优化
运行 run_loop.py，自动将 eval 集 60/40 拆分为训练/测试，Claude 自动提案并打分，最终取测试集最优的 description。
🤔 这一步的目的是：Skill 写得再好，如果 Claude 不知道"该调用它"，一切都是零。

---

第四章：对比与边界 ── 别把这三件事混为一谈

4.1 概念对比表

维度	skill-creator	普通 Prompt 工程	MCP Tool
本质	把工作流沉淀为可复用 Skill 的元级别流程	直接优化单次对话的指令	给 Claude 接入外部 API 能力
适用场景	需要反复执行、跨会话复用的复杂工作流	一次性任务或简单定制	Claude 本身无法完成的外部集成（搜索/DB/文件）
核心机制	draft → eval → iterate → package 闭环	写 → 测 → 改（无结构约束）	定义 schema + 暴露 endpoint
核心限制	需要有「可重复验证」的成功标准	难以量化，无系统性迭代	依赖外部服务稳定性，无内部知识沉淀
典型错误理解	❌ 把它当成「写一段 system prompt」	❌ 以为调参调到满意就完成了	❌ 以为接入了工具就等于有了能力

4.2 反例：这个场景不适合用 skill-creator

场景：产品经理让你帮她优化一封给客户的道歉邮件，只需要润色一次即可。

不适合的原因：skill-creator 的核心价值在于可复用 + 可测试 + 可迭代。一封一次性邮件没有"下次还要用"的诉求，也没有「成功标准可被断言验证」的量化空间。

强行用 skill-creator 处理这种场景，等于专程请菜谱编辑长来煎了一个荷包蛋——工具没有错，只是大材小用，而且会慢很多。

---

一句话带走：skill-creator 是「把隐性工作流显性化、把一次性经验资产化」的工程方法论。它不是写 Prompt，是在构建一套可被验证的能力基础设施。

如有纰漏或者错误，欢迎指正。