运行 skill，顺便优化skill

Skill 执行、验证与证据驱动改进协议 一、任务信息 当前任务：【填写要完成的具体任务】 目标 Skill：【填写 Skill 名称或路径】 最终交付物：【填写文件、代码、页面、报告或其他结果】 完成标准：【填写功能、格式、正确性、视觉、测试等要求】 允许修改目标 Skill：【允许 / 不允许】 允许创建辅助文件或脚本：【允许 / 不允许】 允许修改项目通用规则：【允许 / 仅提出建议 / 不允许】 其他限制：【填写禁止修改的文件、时间限制、安全要求等】 二、总目标 你需要完成两件事： 正确完成当前任务，并验证真实结果。 把本次执行作为目标 Skill 的一次真实测试，在有充分证据时修复可复用的问题。 当前任务始终优先。 不要为了复盘、改写 Skill、减少 Token 或建立文档而降低当前任务结果。 允许最终结论为： 本次没有发现值得修改的 Skill 问题，因此保留原版本。 三、根据任务自动选择执行深度 不要对所有任务使用相同规模的复盘。 1. 轻量模式 满足以下情况时使用： 任务简单； Skill 指令清楚； 没有发生错误或返工； 没有发现可复用缺陷； 不需要修改 Skill。 执行： 阅读目标 SKILL.md； 完成任务； 验证结果； 简短说明是否发现 Skill 问题。 不需要创建 eval、FAQ、CHANGELOG 或辅助目录。 2. 标准模式 满足以下任意情况时使用： Skill 存在歧义； 缺少关键步骤； 出现错误、返工或重复搜索； 需要临时补救； 有明确的可复用改进； 准备修改 Skill。 执行完整的任务验证、问题分类、最小修改和回归检查。 3. 完整模式 只有满足以下任意情况时使用： Skill 主流程发生明显改动； Skill 涉及高风险操作； 修改可能影响大量任务； Skill 经常使用； 需要验证触发准确性； 修改后存在明显回归风险； 用户明确要求严格评测。 可以增加隔离会话、子 Agent、独立进程、旧版与新版对比或更完整的评测。 四、执行当前任务 1. 建立必要上下文 开始前： 找到并阅读目标 SKILL.md。 找到当前目录适用的项目规则： Codex 优先检查适用的 AGENTS.md； Claude Code 优先检查适用的 CLAUDE.md 和路径规则； 如果项目使用其他规则文件，遵循现有项目约定。 只读取本次任务需要的支持文件。 不要默认遍历或完整读取： references/ examples/ assets/ evals/ FAQ.md CHANGELOG.md 其他大型文档 只有满足下面条件时才读取： SKILL.md 明确要求； 当前问题与该文件直接相关； 需要验证已有处理方式； 准备修改对应文件； 需要确认是否已经存在相同内容。 2. 检查修改基线 如果任务会修改文件： 检查 Git 状态和现有 diff； 识别用户已有但尚未提交的修改； 不覆盖、不回滚、不格式化无关修改； 只修改任务范围内的文件。 如果没有 Git，并且准备修改目标 Skill，只备份计划修改的文件，不要复制整个项目。 除非用户明确要求，不要创建 Git commit。 3. 明确完成标准 根据用户要求、项目规则和 Skill 内容，确认： 什么结果算完成； 哪些错误不能接受； 应运行哪些测试或检查； 哪些结果需要真实运行或人工判断； 哪些边界情况与本次任务有关。 如果完成标准不完整，使用当前上下文做合理补全。 只有缺少的信息会直接影响结果、安全或不可逆操作时，才向用户询问。 4. 使用现有 Skill 执行任务 默认先按照当前 Skill 执行。 但如果发现以下阻断性问题，可以先做最小修复，再继续： Skill 文件无法解析； 引用了不存在的必要文件； 命令已经明确失效； 路径明显错误； 会覆盖用户数据； 会泄露凭据； 会执行不可逆危险操作； 不修复就无法完成当前任务。 这种修改必须记录为“执行前阻断性修复”，不能假装原 Skill 正常工作。 5. 记录有效证据 执行过程中只记录会影响 Skill 判断的问题，不记录冗长过程日志，也不要输出内部思维过程。 每个问题最多记录： **现象：**实际发生了什么； **证据：**文件、命令结果、报错、返工或输出差异； **临时处理：**本次如何继续； **验证：**如何确认临时处理有效； **复发可能：**是否可能再次出现。 重点关注： 缺少必要输入； 步骤顺序错误； 指令歧义； 重复搜索相同资料； 重复生成相同命令； 不必要的大文件读取； Skill 与真实环境不一致； 缺少结果验证； 缺少错误恢复； 只能靠猜测完成的步骤； Skill 导致无关文件被修改。 五、先验证任务，再处理 Skill 当前任务完成后，先验证交付结果。 根据任务类型选择适用检查，例如： 自动化测试； lint； 类型检查； 构建； 页面或程序真实运行； 截图或视觉检查； 输入输出对照； 文件格式检查； 数据完整性检查； 链接检查； 日志检查； 与完成标准逐项比较； 检查 diff 中是否存在无关修改。 验证必须检查真实结果。 下面这些不能单独作为完成证明： 文件已经生成； 命令没有报错； Skill 已经运行； 代码看起来正确； 测试文件已经创建； 页面能够打开。 如果验证失败： 先修复当前任务； 重新运行相关验证； 当前任务通过后，再复盘 Skill。 六、判断问题应该放在哪里 对每个真实问题进行分类。 1. 修改 SKILL.md 适用于： 主流程顺序错误； 缺少必要步骤； 输入输出不明确； 缺少完成标准； 缺少失败处理； 触发范围错误； 指令存在稳定歧义； Skill 会重复产生较差结果。 SKILL.md 只保留每次执行都需要知道的内容： 用途和触发范围； 必要输入； 主流程； 关键判断； 验收标准； 失败处理； 支持文件的读取条件。 2. 放入 references/ 或示例文件 适用于： 详细 API 说明； 稳定的平台规则； 字段定义； 设计规范； 较长示例； 低频边界情况； 不需要每次加载的知识。 必须在 SKILL.md 中说明明确读取条件，例如： 当接口返回非 2xx 状态码时，读取 references/api-errors.md。 不要写成模糊的： 有问题时查看 references。 参考资料应包含： 用途； 适用范围； 信息来源； 最后检查日期； 可能过期的部分； 重新检查条件。 3. 放入 FAQ 或 troubleshooting 适用于： 同类错误重复出现； 首次出现但排查成本很高； 解决步骤已经验证； 下次大概率再次发生； 不适合写进主流程。 每条记录包含： 现象； 适用条件； 原因； 解决步骤； 验证方式； 常见错误做法； 相关文件或命令； 最后验证日期。 不要保存未经验证的猜测。 4. 创建脚本 只适用于规则明确、结果确定的重复操作，例如： 文件批处理； 格式转换； 数据检查； 固定命令组合； 构建和测试组合； 结果比较； 项目状态收集。 脚本需要： 明确输入和输出； 参数检查； 使用说明或 --help； 正确退出状态； 清楚的错误信息； 默认不执行危险操作； 不保存密码、Token、Cookie 或其他凭据； 可以单独测试； 在 SKILL.md 中说明运行条件。 不要用脚本代替需求判断、内容创作或审美判断。 5. 修改项目规则 适用于整个项目的长期约定，例如： 项目目录结构； 启动、测试和构建命令； 编码规范； 禁止修改的区域； 项目级验收标准； 固定环境要求。 根据平台放入： Codex：适用范围内的 AGENTS.md； Claude Code：适用范围内的 CLAUDE.md 或路径规则； 其他环境：现有项目说明文件。 只有问题确实适用于整个项目，并且用户允许修改项目规则时，才能直接修改。 否则只提出建议。 6. 使用 Hook 或确定性配置 只有某个动作必须自动发生，不能依赖模型主动记住时才考虑，例如： 编辑后自动格式化； 阻止危险命令； 提交前运行固定检查； 会话结束时执行固定审计； 修改特定文件后运行验证。 仅在当前平台支持、用户允许并且行为已经验证时创建。 7. 不做永久修改 以下问题通常不应写入 Skill： 本次输入缺失； 临时网站故障； 一次性文件损坏； 当前机器缺少依赖； 权限不足； 用户本次的特殊要求； 无法稳定自动判断的审美问题； 没有足够证据的推测。 七、修改门槛 只有候选修改同时满足下面条件时才实施： 本次执行中有实际证据； 问题可能再次出现，或单次影响足够严重； 问题确实属于目标 Skill； 修改能提高正确性、稳定性或可验证性； 没有更小、更合适的处理位置； 修改不会明显降低其他任务的适用性； 修改效果能够检查或测试。 不要因为下面原因修改： 只是理论上可能发生； 只是想让 Skill 看起来更完整； 只是把本次执行日志保存下来； 新内容与现有内容重复； 只适用于当前输入； 无法解释修改解决了什么； 修改后只会让 Skill 更长。 八、实施 Skill 修改 确认值得修改后： 使用最小 diff； 保留原有正确能力； 删除被新内容替代的重复规则； 不修改无关文件； 不创建空目录或空文件； 不把详细知识全部塞进 SKILL.md； 不保存任何秘密信息； 不提交 Git commit，除非用户明确要求； 如果目标 Skill 为只读，创建可编辑改进副本，并说明路径和迁移方式。 Skill 的名称和描述需要明确说明： 它做什么； 什么时候应该触发； 什么时候不应该触发； 关键触发词或典型请求。 关键用途和触发条件放在描述前面，不要用长篇背景占据开头。 九、评测和回滚 1. 轻微修改 对于错别字、明确路径、单句歧义或支持文件索引调整，可以执行： 文件格式检查； 链接或路径检查； 使用本次任务重新验证； 检查 diff。 不必强制建立完整评测集。 2. 实质修改 如果修改了主流程、触发范围、关键判断或错误处理，至少保留： 本次暴露问题的回归案例； 一个正常案例； 一个相关边界案例。 只有触发范围发生变化时，才增加“不应该触发”的案例。 每个案例包含： 输入； 是否应该触发； 预期结果； 必须满足的检查项； 不能出现的结果； 验证方式。 3. 前后比较 条件允许时比较旧版和新版： 最终结果正确性； 本次问题是否消失； 原有能力是否保留； 是否产生新错误； 是否减少重复搜索； 是否减少不必要文件读取； 是否减少返工； 是否更容易验证； 工具调用是否减少。 只有能够获得真实 Token 统计时，才报告 Token 数量。 没有统计时写“未测量”，不要估算。 如果新版： 结果变差； 出现回归； 只适用于本次任务； 明显增加无关上下文； 无法通过必要验证； 则回滚或缩小修改。 十、变更记录 只有 Skill 实际发生了有意义的修改时，才更新现有 CHANGELOG.md。 如果项目没有变更记录，并且修改很小，不要为了形式强制创建。 变更记录应写明： 日期； 实际问题； 证据； 修改内容； 修改文件； 验证方式； 验证结果； 兼容性影响； 未解决问题； 回滚方式。 不要写“优化流程”“提高质量”之类无法判断的描述。 十一、最终输出 最终报告保持简短，只输出实际有内容的部分。 1. 当前任务结果 完成内容； 交付物位置； 验证方式； 验证结果； 已知限制。 2. Skill 复盘问题实际证据分类处理决定 没有发现问题时直接写： 本次执行未发现有充分证据支持的 Skill 修改，保留原版本。 3. 实际修改文件修改内容原因验证 没有修改时省略本节。 4. 前后验证检查项修改前修改后结论 只有实际进行了前后比较时才输出。 5. 新增长期资产 只列实际新增或更新的： reference； FAQ； 脚本； eval； 项目规则； Hook； 读取或运行条件； 更新触发条件。 没有新增时省略本节。 6. 未解决问题 只列真实存在、会影响后续使用的问题。 没有时省略本节。 十二、最终判断标准 本次工作成功需要满足： 当前任务结果正确并经过验证； Skill 问题有真实证据； 修改放在正确的文件或机制中； 修改后没有破坏原有能力； 改进可以被检查或复现； 没有为了改进而强行修改； 没有为了节省 Token 而降低质量； 没有让默认加载的 Skill 内容无意义地增长。 现在执行当前任务。先完成并验证任务，再根据真实证据决定是否修改 Skill。