名称: 治愈技能 描述: 当技能有错误的指令或过时的 API 引用时，修复不正确的 SKILL.md 文件
参数
[对象对象]
允许的工具
- 读取
- 编辑
- Bash(ls:*)
- Bash(git:*)
<目标> 根据在执行过程中发现的更正，更新一个技能的 SKILL.md 及相关文件。
分析对话以检测哪个技能正在运行，反思出了什么问题，提出具体修复方案，获取用户批准，然后应用更改并可选地提交。 </目标>
<上下文>
技能检测: !ls -1 ./skills/*/SKILL.md | head -5
</上下文>
<快速开始> <工作流程>
- 检测技能 从对话上下文（调用消息、最近引用的 SKILL.md）
- 反思 出了什么问题以及如何发现修复方案
- 呈现 提出的更改，带有前后差异
- 获取批准 在进行任何编辑之前
- 应用 更改并可选地提交 </工作流程> </快速开始>
<过程> <步骤_1 名称=“检测技能”> 从对话上下文中识别技能：
- 查找技能调用消息
- 检查最近引用了哪个 SKILL.md
- 检查当前任务上下文
设置: SKILL_NAME=[技能名称] 和 SKILL_DIR=./skills/$SKILL_NAME
如果不清楚，询问用户。 </步骤_1>
<步骤_2 名称=“反思与分析”> 如果提供了 $ARGUMENTS，则关注它，否则分析更广泛的上下文。
确定：
- 出了什么问题：从 SKILL.md 中引用不正确的具体部分
- 发现方法：上下文、错误消息、试错法、文档查找
- 根本原因：过时的 API、不正确的参数、错误的端点、缺少上下文
- 影响范围：单个部分或多个部分？相关文件是否受影响？
- 提出的修复：哪些文件、哪些部分、每个的前后版本 </步骤_2>
<步骤_3 名称=“扫描受影响文件”>
ls -la $SKILL_DIR/
ls -la $SKILL_DIR/references/ 2>/dev/null
ls -la $SKILL_DIR/scripts/ 2>/dev/null
</步骤_3>
<步骤_4 名称=“呈现提出的更改”> 以这种格式呈现更改：
**正在治愈的技能：** [技能名称]
**发现的问题：** [1-2句总结]
**根本原因：** [简要解释]
**要修改的文件：**
- [ ] SKILL.md
- [ ] 参考/[文件].md
- [ ] 脚本/[文件].py
**提出的更改：**
### 更改 1：SKILL.md - [部分名称]
**位置：** SKILL.md 的第 [X] 行
**当前（不正确）：**
[从当前文件中提取的准确文本]
**更正后：**
[新文本]
**原因：** [为什么这能修复问题]
[为所有文件中的每个更改重复]
**影响评估：**
- 影响： [认证/API 端点/参数/示例/等]
**验证：**
这些更改将防止： [引发此次修复的特定错误]
</步骤_4>
<步骤_5 名称=“请求批准”>
我应该应用这些更改吗？
1. 是的，应用并提交所有更改
2. 应用但不提交（让我先审查）
3. 修订更改（我将提供反馈）
4. 取消（不进行更改）
选择 (1-4):
等待用户响应。未获批准前不要继续。 </步骤_5>
<步骤_6 名称=“应用更改”> 仅在批准后（选项 1 或 2）：
- 为每个文件使用编辑工具进行每个更正
- 回读修改部分以验证
- 如果选择选项 1，提交并带有结构化消息显示治愈的内容
- 确认完成并列出文件 </步骤_6> </过程>
<成功标准>
- 从对话上下文中正确检测技能
- 所有不正确部分都有前后对比识别
- 用户批准更改前应用
- 所有编辑应用于 SKILL.md 及相关文件
- 通过回读验证更改
- 如果用户选择选项 1，创建提交
- 完成确认并列出文件 </成功标准>
<验证> 在完成前：
- 回读每个修改部分以确认应用更改
- 确保跨文件一致性（SKILL.md 示例匹配参考/）
- 验证 git 提交如果选项 1 被选择
- 检查没有无意中修改的文件 </验证>