byte886 把跑通的方法沉淀成 Skill
把真实执行中已经验证有效的部分提炼出来，生成一份简洁、可复用、可验证的 Skill。不要把整段聊天记录换个格式，也不要把未经验证的设想包装成成熟流程。
核心原则
- 先跑通，再沉淀。 没有成功结果时，先帮助用户继续完成或排查原任务，不创建正式 Skill。
- 先判断载体，再创建文件。 一次性要求可能只需要 Prompt；固定人工步骤可能适合 SOP 或模板；重复、稳定且可验收的流程才适合 Skill。
- 只固化稳定方法。 区分必需步骤、本次特例、失败尝试和偶然绕路。
- 人负责边界和验收。 涉及发布、发送、删除、覆盖、付款、授权或重要数据修改时，保留人工确认点。
- 用新样本验证。 原案例成功只能证明“这次能用”；换样本、换对话后仍能执行，才能证明“可以复用”。
第一步：确认有足够证据
优先读取当前对话和工作区中的原始证据：
- 用户最初提出的任务；
- 实际使用的输入文件、链接或数据；
- Agent 的执行计划、工具调用和日志；
- 成功交付的文件、文档或消息；
- 用户提出的修改意见和最终确认；
- 执行过程中出现的报错、无效尝试和修复方法。
不要仅凭一段事后概述推测流程。当前对话没有完整现场时，请用户提供运行记录、结果文件或相关路径。最多一次追问 3 个最关键的问题。
把证据状态标为以下一种：
- 已验证：有成功结果和明确验收；
- 部分验证：任务完成，但缺少质量检查或边界信息；
- 尚未验证：没有成功结果，或只能看到计划而看不到交付物。
“尚未验证”时停止创建正式 Skill，只输出缺口和下一步验证动作。
第二步：判断沉淀载体
| 载体 | 适用条件 | 本次产物 |
|---|---|---|
| Prompt | 一次性任务，规则很少，后续不一定重复 | 可复制的任务指令 |
| SOP | 步骤较固定，但主要由人执行 | 操作步骤和检查清单 |
| 模板 | 结构稳定，主要变化是填入内容 | 可复用的输出骨架 |
| Skill | 同类任务会重复；触发条件、输入输出、流程和验收标准相对稳定 | 标准 Skill 文件夹 |
| Agent | 需要长期值班、主动触发、记忆、调度或多个 Skill 协作 | 只提出升级建议，不在本流程中直接扩建 |
如果不适合做 Skill，明确告诉用户原因，并提供更轻量的载体草稿。不要为了完成指令而强行创建 Skill。
只有以下条件大体成立时才继续：
- 同类任务以后还会出现；
- 输入和交付物能够描述；
- 核心流程已经真实执行成功；
- 好坏有可以检查的标准；
- 异常和高风险边界能够说明。
第三步：提炼可复用方法
从证据中提取以下内容：
- 目标：这项能力替用户完成什么工作。
- 触发条件：用户在什么场景、用什么说法时应该调用。
- 不适用场景：哪些相似请求不应该触发。
- 输入：必需材料、可选参数和缺失时需要追问的信息。
- 稳定流程：每次都要执行的步骤及其顺序。
- 工具策略：需要什么能力，以及选择工具的判断标准。
- 异常处理：常见失败、重试条件、替代方案和停止条件。
- 人工确认点：哪些动作必须由用户决定。
- 交付物：最终要返回什么、保存到哪里。
- 验收标准：如何证明结果完整、正确、可打开、可继续使用。
清理以下内容：
- Token、密码、Cookie、App Secret 和其他凭据；
- 私人信息和与复用无关的业务数据；
- 本机用户名、一次性绝对路径和临时文件名；
- 只属于原案例的链接、日期、标题和数量；
- 已被证明无效的做法；
- Agent 本来就具备、无需反复解释的常识。
失败记录如果能帮助以后避坑，将其转成“异常处理”或“停止条件”，不要混入正常步骤。
第四步：先输出设计摘要
创建文件前，先向用户展示：
建议名称：{lowercase-hyphen-case}
解决的问题：{一句话}
使用场景：{何时触发}
不适用场景：{何时不触发}
输入：{必需输入与可选参数}
稳定流程：{5-10 个关键步骤}
异常处理：{主要失败分支}
人工确认：{高风险或关键判断}
交付物：{输出内容}
验收标准：{完成定义}
证据状态：已验证 / 部分验证
仍需验证：{下一样本要验证什么}
如果用户只要求分析或草稿，到这里停止。用户已明确要求创建且目标位置清楚时，可以继续；目标位置不清楚时，只问一个问题：Skill 要创建到哪里？
第五步：创建目标 Skill
使用环境提供的标准初始化和文件编辑方式创建。目标 Skill 至少包含：
skill-name/
└─ SKILL.md
环境支持时，推荐使用：
skill-name/
├─ SKILL.md
├─ agents/
│ └─ openai.yaml
├─ scripts/ # 仅在确定性操作会反复执行时创建
├─ references/ # 仅放按需读取的规则、知识和详细说明
└─ assets/ # 仅放生成结果时需要复制或使用的模板、素材
遵循以下规则：
- 文件夹名和
name使用 lowercase-hyphen-case，控制在 64 个字符以内； SKILL.mdfrontmatter 只写name和description；description同时写清楚“做什么”和“什么时候用”，使 Agent 能正确触发；- 正文使用指令式表达，保留核心工作流、判断规则、异常处理和验收标准；
- 把详细领域资料放入
references/，把输出模板放入assets/； - 只创建实际需要的目录，不创建 README、安装指南、更新日志等辅助文件；
- 不自动写入全局 Skill 目录，不覆盖同名 Skill；安装或覆盖前必须获得用户明确授权。
如果目标 Skill 已存在，先读取并比较，只提出或实施最小必要更新，不新建重复副本。
第六步：验证目标 Skill
完成后依次检查：
- 文件夹名、frontmatter 和必要文件是否有效；
- 触发条件是否能覆盖真实说法，又不会过度触发；
- 是否遗漏输入、异常、人工确认点或验收标准；
- 是否混入凭据、个人路径或原案例特有参数；
- 是否能在没有原聊天上下文的情况下被另一个 Agent 理解；
- 是否使用第二个不同样本进行测试。
有标准验证脚本时运行验证。只有一个成功样本时，把目标 Skill 标记为“初版，待第二样本验证”，不要宣称它已经成熟。
第二样本测试失败时，优先修改规则、异常处理或验收标准，再重新测试；不要把新样本的全部细节继续硬编码进 Skill。
最终交付
向用户返回：
- 载体判断及理由；
- 新建或修改的 Skill 名称和路径；
- 一句最简单的调用示例；
- 已验证内容和仍需验证内容；
- 第二样本测试结果或推荐的下一步。