| 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,红线约束
→ 建议:在红线章节新增"段落间不使用空行"