name: heal-skill description: 当技能有错误指令或过时API参考时修复不正确的SKILL.md文件
参数
[object Object]
允许的工具
- 读取
- 编辑
- Bash(ls:*)
- Bash(git:*)
<objective> 基于执行中发现的修正更新技能的SKILL.md和相关文件。
分析对话以检测哪个技能正在运行，反思出错原因，提出具体修复，获得用户批准，然后应用更改并可选提交。 </objective>
<context>
技能检测：!ls -1 ./skills/*/SKILL.md | head -5
</context>
<quick_start> <workflow>
- 检测技能 从对话上下文（调用消息、最近的SKILL.md参考）
- 反思 出错原因及如何发现修复
- 呈现 提出的更改及前后差异
- 获得批准 在进行任何编辑前
- 应用 更改并可选提交 </workflow> </quick_start>
<process> <step_1 name=“detect_skill”> 从对话上下文中识别技能：
- 查找技能调用消息
- 检查哪个SKILL.md最近被参考
- 检查当前任务上下文
设置：SKILL_NAME=[技能名称] 和 SKILL_DIR=./skills/$SKILL_NAME
如果不清楚，询问用户。 </step_1>
<step_2 name=“reflection_and_analysis”> 如果提供 $ARGUMENTS，则关注它，否则分析更广泛的上下文。
确定：
- 出错原因：引用SKILL.md中不正确的具体部分
- 发现方法：上下文7、错误消息、试错、文档查找
- 根本原因：过时API、错误参数、错误端点、缺少上下文
- 影响范围：单个部分或多个？相关文件受影响？
- 提出的修复：哪些文件、哪些部分、每个的前后 </step_2>
<step_3 name=“scan_affected_files”>
ls -la $SKILL_DIR/
ls -la $SKILL_DIR/references/ 2>/dev/null
ls -la $SKILL_DIR/scripts/ 2>/dev/null
</step_3>
<step_4 name=“present_proposed_changes”> 以以下格式呈现更改：
**正在修复的技能：** [技能名称]
**发现的问题：** [1-2句摘要]
**根本原因：** [简短解释]
**要修改的文件：**
- [ ] SKILL.md
- [ ] references/[文件].md
- [ ] scripts/[文件].py
**提出的更改：**
### 更改1：SKILL.md - [部分名称]
**位置：** SKILL.md中的行[X]
**当前（不正确）：**
[当前文件中的确切文本]
**更正后：**
[新文本]
**原因：** [为什么这能解决问题]
[对所有文件的每个更改重复]
**影响评估：**
- 影响： [认证/API端点/参数/示例等]
**验证：**
这些更改将防止： [提示此修复的具体错误]
</step_4>
<step_5 name=“request_approval”>
是否应用这些更改？
1. 是，应用并提交所有更改
2. 应用但不提交（让我先审查）
3. 修订更改（我将提供反馈）
4. 取消（不做更改）
选择（1-4）：
等待用户响应。未经批准不得继续。 </step_5>
<step_6 name=“apply_changes”> 仅在批准后（选项1或2）：
- 使用编辑工具对每个更正应用于所有文件
- 读回修改部分以验证
- 如果选择选项1，用结构化消息提交，显示修复内容
- 用文件列表确认完成 </step_6> </process>
<success_criteria>
- 技能从对话上下文正确检测
- 所有不正确的部分及前后差异已识别
- 用户在应用前批准更改
- 所有编辑已应用于SKILL.md和相关文件
- 通过读回验证更改
- 如果用户选择选项1，已创建提交
- 完成已用文件列表确认 </success_criteria>
<verification> 在完成前：
- 读回每个修改部分以确认更改已应用
- 确保跨文件一致性（SKILL.md示例匹配references/）
- 验证如果选择选项1，git提交已创建
- 检查没有意外文件被修改 </verification>