| name | skill-improve |
| description | 当用户要求"改进Skill"、"优化Skill"、"Skill反馈"、"批量改进"、"把这些问题记下来"、"更新Skill规范"时使用此Skill。用于从对话历史中自动提取负反馈，批量生成Skill改进建议。 |
| version | 1.0.0 |
Skill 改进工具
本 Skill 是一个元工具，用于将使用其他 Skill 时产生的负反馈转化为对该 Skill 的改进建议。
核心设计原则：AI 主动分析，用户只需确认
使用流程
第一步：自动分析对话历史
回顾当前会话的完整对话历史，自动提取：
-
识别负反馈：
- 用户明确指出的错误（如"这里不对"、"应该是..."）
- 用户的修正意见（如"改成..."、"不要..."）
- 用户表达的不满或困惑（如"为什么..."、"这不符合..."）
- 领导/同事的修改意见（用户转述的）
- 格式、用词、结构等方面的问题
-
识别相关 Skill：
- 根据对话上下文判断涉及哪个 Skill
- 如果对话中使用了多个 Skill，分别标记
输出格式：
## 对话分析结果
### 识别到的负反馈
| # | 负反馈内容 | 关联 Skill | 反馈来源 |
|---|-----------|-----------|----------|
| 1 | [具体问题] | [skill-name] | 用户指出 / 领导意见 |
| 2 | ... | ... | ... |
### 涉及的 Skill
- gongwen（3 条反馈）
- convert-quotes（1 条反馈）
---
请确认以上分析是否正确？是否有遗漏或多余？
等待用户确认后才进入下一步。
第二步：读取目标 Skill
用户确认后，读取所有涉及的 Skill 文件：
- 每个 Skill 的 SKILL.md 主文件
- 每个 Skill 的 references/ 目录下所有文件
目的：理解现有规范，找出问题对应的位置。
第三步：分析问题归属
针对每条负反馈，判断其属于哪种类别：
| 类别 | 定义 | 处理方式 |
|---|
| 规则缺失 | Skill 中未定义相关规则 | 新增规则章节 |
| 规则模糊 | 规则存在但描述不清晰 | 补充说明或重写 |
| 缺少示例 | 规则清晰但缺乏样例 | 添加正反例 |
| 红线约束 | 某些情况应明确禁止 | 添加到红线章节 |
| 流程问题 | 步骤顺序或遗漏 | 调整流程设计 |
输出格式：
## 问题归属分析
| # | 负反馈内容 | 问题类别 | 现有规范位置 | 改进方向 |
|---|-----------|----------|-------------|----------|
| 1 | [问题] | 规则缺失 | 无 | 新增"XX规范"章节 |
| 2 | [问题] | 规则模糊 | core.md 第45行 | 补充说明 |
---
请确认以上问题归属是否正确？
等待用户确认后才进入下一步。
第四步：生成改进建议
用户确认问题归属后，为每条反馈生成具体的改进建议：
## Skill 改进建议
### 改进 #1
**目标 Skill**: gongwen
**当前版本**: 1.0.0 → **建议版本**: 1.1.0
**问题类别**: 规则缺失
**问题描述**:
[具体问题]
**建议修改**:
- **文件**: `references/core.md`
- **位置**: "用词规范"章节后
- **操作**: 新增
**新增内容**:
XX规范
- 规则一
- 规则二
**修改理由**:
[为什么需要这个修改]
---
### 改进 #2
...
---
请确认以上改进建议是否正确？确认后我将执行修改。
等待用户确认后才执行修改。
第五步：执行修改
用户确认后，批量执行所有改进：
- 修改对应的 Skill 文件
- 更新每个被修改 Skill 的 version 字段
- 输出修改摘要
## 修改完成
| Skill | 版本变化 | 修改文件 | 改动数 |
|-------|----------|----------|--------|
| gongwen | 1.0.0 → 1.1.0 | core.md, SKILL.md | 2 |
| convert-quotes | 1.0.0 → 1.0.1 | SKILL.md | 1 |
所有改进已应用。
版本更新规则
采用语义化版本：major.minor.patch
| 改动类型 | 版本变化 | 示例 |
|---|
| 修复错别字、微调措辞 | patch +1 | 1.0.0 → 1.0.1 |
| 新增规则、新增示例、补充说明 | minor +1 | 1.0.0 → 1.1.0 |
| 重构流程、重大结构变化 | major +1 | 1.0.0 → 2.0.0 |
红线约束
-
三次确认原则：
- 第一次：确认负反馈和关联 Skill 是否正确
- 第二次：确认问题归属是否正确
- 第三次：确认改进建议后才执行修改
-
不修改正在使用的 Skill：如果当前任务正在使用某 Skill 且尚未完成，先完成任务再改进
-
保留原有结构：除非必要，不改变 Skill 的整体结构
-
向后兼容：新规则不应与现有规则产生矛盾
-
只增不删：默认只增加或修改内容，不主动删除（除非用户明确要求）
-
合并同类项：如果多条反馈指向同一个问题，合并为一条改进建议
常见场景示例
场景一：公文撰写后收到领导修改意见
用户："领导说'一号工程'要加引号，改进一下 Skill"
→ 自动识别：gongwen Skill，规则缺失
→ 建议：在 core.md 新增"专有名词引用规范"
场景二：长对话后批量改进
用户："把今天对话里的问题都整理一下，改进相关 Skill"
→ 自动回顾整个对话历史
→ 提取所有负反馈
→ 分类归属
→ 批量生成改进建议
场景三：格式问题
用户："刚才的报告格式不对，段落之间不该有空行"
→ 自动识别：gongwen Skill，红线约束
→ 建议：在红线章节新增"段落间不使用空行"
