| name | experience-to-skill |
| description | 将经验提炼为 Skill。当用户分享方法论、工作流程、最佳实践、经验贴，或说"把这个变成 Skill"/"总结一下"时使用。自动执行：理解经验 → 跑通验证 → 复盘正负向 → 封装为 Skill → 安排回溯测试。核心原则：先跑通再封装，不要凭空设计。 |
经验提炼为 Skill
触发条件
- 用户分享经验贴、方法论、最佳实践
- 用户说"把这个变成 Skill"、"总结成 Skill"、"以后也这样做"
- 用户分享一个可复用的工作流程
核心原则
先跑通，再封装。不是先设计，再验证。
Skill 本质是人把场景 SOP 化的能力。不是设计出来的，是从成功执行中提炼出来的。
四步流程
Step 1: 跑通（Execute）
- 理解经验的核心目标
- 在当前真实场景中执行一遍
- 不求完美，拿到一个认可的结果
- 记录每一步做了什么、遇到什么问题
Step 2: 复盘（Review）
- 哪些流程是正向的（保留）
- 哪些流程是负向的（改进）
- 哪些是浪费时间的（删除）
- 识别当前流程中的 2-3 个关键问题
Step 3: 封装（Package）
- 创建
skills/<skill-name>/SKILL.md
- 遵循三层结构：
- 第一层：name + description（触发条件，要写清具体场景）
- 第二层：SKILL.md 主流程（Step by step，可执行）
- 第三层：参考资料（scripts/assets/references，按需）
- description 要明确告诉模型"什么时候用"，不要写太泛
Step 4: 回溯测试（Backtest）
- 安排下一次触发时验证
- 检查：能否稳定复现？哪里不稳定？
- 不稳定 → 定位问题 → 优化 Skill → 再测
- 稳定 → 标记为可用
Skill 迭代规则
像做产品一样迭代，每个版本只解决一个最关键的问题：
| 版本 | 目标 |
|---|
| 1.0 | 能不能跑通（60分） |
| 2.0 | 解决最明显的问题（70分） |
| 3.0 | 引入高级特性如 subagent（80分） |
| 4.0 | 减少人工干预，更自动化（90分） |
不要一开始就追求完美。先跑起来，一轮轮解决关键问题。
两种场景的处理
- 用户熟悉的领域 → 经验蒸馏，把用户的经验拆成 AI 能执行的流程
- 用户不熟悉的领域 → 建立回溯验证机制（能判断对不对才重要）
如果无法建立验证机制（如六爻占卜），坦诚告知用户这个场景不适合 Skill 化。
Skill 目录结构
skills/<skill-name>/
├── SKILL.md # 主流程（必须）
├── scripts/ # 辅助脚本（可选）
├── assets/ # 素材/模板（可选）
└── references/ # 参考文档（可选）
命名规范
- 目录名：英文短横线分隔，如
knowledge-archive
- SKILL.md 的 name 字段：与目录名一致
- description：一句话说清场景，如"当用户发送知识链接时，自动存档并汇报"
输出汇报
完成封装后，告知用户：
- 创建了什么 Skill
- 解决什么问题
- 下一步回溯测试计划
