# Turn Run Into Skill

> 将一条已经成功跑通的真实任务，从聊天记录、执行日志、输入输出文件和用户反馈中提炼为可复用 Skill。用于用户说“把刚才的流程沉淀成 Skill”“把这次成功经验固化下来”“以后重复做这类任务”“从运行记录生成 SKILL.md”时；也用于判断当前经验更适合保存为 Prompt、SOP、模板还是 Skill。不要用于尚未跑通、没有可验证结果，或用户只是想执行原始业务任务的场景。

- Skill: `byte886/turn-run-into-skill` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add byte886/turn-run-into-skill`
- Raw SKILL.md: https://api.skillmd.com/api/skills/byte886/turn-run-into-skill/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: byte886 (https://skillmd.com/u/byte886)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/byte886/turn-run-into-skill

---


# 把跑通的方法沉淀成 Skill

把真实执行中已经验证有效的部分提炼出来，生成一份简洁、可复用、可验证的 Skill。不要把整段聊天记录换个格式，也不要把未经验证的设想包装成成熟流程。

## 核心原则

1. **先跑通，再沉淀。** 没有成功结果时，先帮助用户继续完成或排查原任务，不创建正式 Skill。
2. **先判断载体，再创建文件。** 一次性要求可能只需要 Prompt；固定人工步骤可能适合 SOP 或模板；重复、稳定且可验收的流程才适合 Skill。
3. **只固化稳定方法。** 区分必需步骤、本次特例、失败尝试和偶然绕路。
4. **人负责边界和验收。** 涉及发布、发送、删除、覆盖、付款、授权或重要数据修改时，保留人工确认点。
5. **用新样本验证。** 原案例成功只能证明“这次能用”；换样本、换对话后仍能执行，才能证明“可以复用”。

## 第一步：确认有足够证据

优先读取当前对话和工作区中的原始证据：

- 用户最初提出的任务；
- 实际使用的输入文件、链接或数据；
- Agent 的执行计划、工具调用和日志；
- 成功交付的文件、文档或消息；
- 用户提出的修改意见和最终确认；
- 执行过程中出现的报错、无效尝试和修复方法。

不要仅凭一段事后概述推测流程。当前对话没有完整现场时，请用户提供运行记录、结果文件或相关路径。最多一次追问 3 个最关键的问题。

把证据状态标为以下一种：

- **已验证**：有成功结果和明确验收；
- **部分验证**：任务完成，但缺少质量检查或边界信息；
- **尚未验证**：没有成功结果，或只能看到计划而看不到交付物。

“尚未验证”时停止创建正式 Skill，只输出缺口和下一步验证动作。

## 第二步：判断沉淀载体

|载体|适用条件|本次产物|
|---|---|---|
|Prompt|一次性任务，规则很少，后续不一定重复|可复制的任务指令|
|SOP|步骤较固定，但主要由人执行|操作步骤和检查清单|
|模板|结构稳定，主要变化是填入内容|可复用的输出骨架|
|Skill|同类任务会重复；触发条件、输入输出、流程和验收标准相对稳定|标准 Skill 文件夹|
|Agent|需要长期值班、主动触发、记忆、调度或多个 Skill 协作|只提出升级建议，不在本流程中直接扩建|

如果不适合做 Skill，明确告诉用户原因，并提供更轻量的载体草稿。不要为了完成指令而强行创建 Skill。

只有以下条件大体成立时才继续：

- 同类任务以后还会出现；
- 输入和交付物能够描述；
- 核心流程已经真实执行成功；
- 好坏有可以检查的标准；
- 异常和高风险边界能够说明。

## 第三步：提炼可复用方法

从证据中提取以下内容：

1. **目标**：这项能力替用户完成什么工作。
2. **触发条件**：用户在什么场景、用什么说法时应该调用。
3. **不适用场景**：哪些相似请求不应该触发。
4. **输入**：必需材料、可选参数和缺失时需要追问的信息。
5. **稳定流程**：每次都要执行的步骤及其顺序。
6. **工具策略**：需要什么能力，以及选择工具的判断标准。
7. **异常处理**：常见失败、重试条件、替代方案和停止条件。
8. **人工确认点**：哪些动作必须由用户决定。
9. **交付物**：最终要返回什么、保存到哪里。
10. **验收标准**：如何证明结果完整、正确、可打开、可继续使用。

清理以下内容：

- Token、密码、Cookie、App Secret 和其他凭据；
- 私人信息和与复用无关的业务数据；
- 本机用户名、一次性绝对路径和临时文件名；
- 只属于原案例的链接、日期、标题和数量；
- 已被证明无效的做法；
- Agent 本来就具备、无需反复解释的常识。

失败记录如果能帮助以后避坑，将其转成“异常处理”或“停止条件”，不要混入正常步骤。

## 第四步：先输出设计摘要

创建文件前，先向用户展示：

```text
建议名称：{lowercase-hyphen-case}
解决的问题：{一句话}
使用场景：{何时触发}
不适用场景：{何时不触发}
输入：{必需输入与可选参数}
稳定流程：{5-10 个关键步骤}
异常处理：{主要失败分支}
人工确认：{高风险或关键判断}
交付物：{输出内容}
验收标准：{完成定义}
证据状态：已验证 / 部分验证
仍需验证：{下一样本要验证什么}
```

如果用户只要求分析或草稿，到这里停止。用户已明确要求创建且目标位置清楚时，可以继续；目标位置不清楚时，只问一个问题：Skill 要创建到哪里？

## 第五步：创建目标 Skill

使用环境提供的标准初始化和文件编辑方式创建。目标 Skill 至少包含：

```text
skill-name/
└─ SKILL.md
```

环境支持时，推荐使用：

```text
skill-name/
├─ SKILL.md
├─ agents/
│  └─ openai.yaml
├─ scripts/       # 仅在确定性操作会反复执行时创建
├─ references/    # 仅放按需读取的规则、知识和详细说明
└─ assets/        # 仅放生成结果时需要复制或使用的模板、素材
```

遵循以下规则：

- 文件夹名和 `name` 使用 lowercase-hyphen-case，控制在 64 个字符以内；
- `SKILL.md` frontmatter 只写 `name` 和 `description`；
- `description` 同时写清楚“做什么”和“什么时候用”，使 Agent 能正确触发；
- 正文使用指令式表达，保留核心工作流、判断规则、异常处理和验收标准；
- 把详细领域资料放入 `references/`，把输出模板放入 `assets/`；
- 只创建实际需要的目录，不创建 README、安装指南、更新日志等辅助文件；
- 不自动写入全局 Skill 目录，不覆盖同名 Skill；安装或覆盖前必须获得用户明确授权。

如果目标 Skill 已存在，先读取并比较，只提出或实施最小必要更新，不新建重复副本。

## 第六步：验证目标 Skill

完成后依次检查：

1. 文件夹名、frontmatter 和必要文件是否有效；
2. 触发条件是否能覆盖真实说法，又不会过度触发；
3. 是否遗漏输入、异常、人工确认点或验收标准；
4. 是否混入凭据、个人路径或原案例特有参数；
5. 是否能在没有原聊天上下文的情况下被另一个 Agent 理解；
6. 是否使用第二个不同样本进行测试。

有标准验证脚本时运行验证。只有一个成功样本时，把目标 Skill 标记为“初版，待第二样本验证”，不要宣称它已经成熟。

第二样本测试失败时，优先修改规则、异常处理或验收标准，再重新测试；不要把新样本的全部细节继续硬编码进 Skill。

## 最终交付

向用户返回：

- 载体判断及理由；
- 新建或修改的 Skill 名称和路径；
- 一句最简单的调用示例；
- 已验证内容和仍需验证内容；
- 第二样本测试结果或推荐的下一步。