skillify git:20260817.d4dfa41A

Immutable. This exact content is served forever at /api/v1/blob/6cdb515b4a13cf3d.

---
name: skillify
description: 把这次会话里摸索出来的可复用流程沉淀成一个技能。提炼步骤、完成判据和用户纠正过的点，和用户确认后写成 SKILL.md。目录与格式细节见 extend-riot 技能。
---

# 沉淀成技能

## 什么值得沉淀

判据：**下次还会做，而且模型光靠常识做不对。**

- 这次会话里用户纠正过你的地方——每处纠正都是一条「模型的默认做法
  在这里不对」的证据，是技能正文里最值钱的原料；
- 试错试出来的顺序、参数、坑（哪个命令要先跑、哪个 flag 不能省、
  哪一步必须等前一步的产物）；
- 用户没有明说、但反复要求的偏好。

反例：模型本来就会的通用流程（「先读文件再改」）写成技能只是噪音，
还占技能清单的位置。

## 提炼

从会话里回答这几个问题；答不出来的用提问工具问用户，一次问完，
不要挤牙膏：

1. **触发场景**是什么？这句话就是 description——模型全靠它决定
   要不要加载这个技能，写不准等于技能不存在。
2. 步骤有哪几步？每步的**完成判据**是什么（产出什么、怎么算成了）？
3. 哪些是硬约束？顺序不能换的、某些文件不能碰的、必须先问用户的。
4. 放哪层：只跟这个项目有关 → 项目 `.riot/skills/`；跨项目通用 →
   全局技能目录。

## 写

- description 写「什么时候用」，不写做法，250 字符以内——超了会被
  截断，模型只能在残句上做判断；
- 正文只写**模型猜不到的**：判据、顺序、坑、约束。每句话问一遍
  「删掉它，模型会做错吗」——不会就删；
- 用户纠正过的点写成明确的「不要做 X，因为 Y」，别客气也别含糊；
- **自由度跟着任务的脆弱程度走**：多解的任务写原则和判据就够
  （审查指南），怕做错的操作写精确的命令和顺序（迁移、发布）。
  给脆弱步骤留发挥空间，等于留 bug；
- 别列一堆可选方案让模型现场挑。给**一个默认做法**，再写清什么
  情况下换另一个；
- 大段参考资料（表格、样例、脚本）放技能目录里的独立文件，正文
  说明什么时候去读哪个。正文塞满资料，每次加载都是全价，用不用
  都付；
- 目录位置、frontmatter 字段、同名优先级这些机制，照 extend-riot
  技能的说明来，不要凭记忆写。

## 写完

把文件路径和 description 给用户过目，说明**下一轮对话生效**。
提醒一句：设置页能看到技能的解析结果，写坏了那里会显示原因。