Skill Optimizer Lawvable

---
name: skill-optimizer-lawvable
description: 分析当前工作会话并为技能提出改进建议的指南。用于 (1) 使用技能后自动捕获经验教训，(2) 当用户在技能相关会话中提出改进、更正或补充建议时，或 (3) 当用户手动调用 `self-improve` 时。
metadata:
  author: Malik Taiar (Lawvable)
  license: AGPL-3.0
  version: 2026.01.07
---

# Self-Improve 技能

分析当前对话，并根据工作会话期间发现的更正、成功和边缘情况为技能提出改进建议。

## 触发

- `self-improve` - 分析会话并提出改进建议
- `self-improve [skill-name]` - 针对特定技能
- `self-improve on` - 启用自动模式（钩子）
- `self-improve off` - 禁用自动模式
- `self-improve status` - 显示自动模式状态
- `self-improve [skill-name] history` - 显示修改历史

---

## 主工作流（`self-improve`）

### 第 1 步：识别技能

若未提供技能名称，列出 `skills/` 目录中的可用技能并询问：

```
本次会话应分析哪个技能？
[列出 skills/ 目录中找到的技能]
```

### 第 2 步：检测信号

扫描对话以寻找**信号**——用户表达反馈的时刻：

| 信号类型 | 示例 |
|-------------|----------|
| **更正** | “No”（不）、“That's not right”（那不对）、“It's missing X”（缺少 X）、“Always do Y”（总是做 Y）、用户重写输出 |
| **成功** | “Perfect”（完美）、“Yes”（是）、“Exactly”（正是如此）、用户无修改接受 |
| **边缘情况** | 用户需要变通方案、技能无法处理该请求 |

### 第 3 步：评估每个信号的质量

对每个更正信号，评估它是否能成为一条好的技能指令。

#### 质量标准

**1. 完整（COMPLETE）**

指令包含应用它所需的全部信息。无需查其他资料或做假设。

| 等级 | 示例 |
|-------|---------|
| 通过 | “将输出结构化为：关键术语 / 风险领域 / 建议修订” |
| 失败 | “使用标准格式”（哪种格式？） |
| 失败 | “遵循我们事务所的准则”（什么准则？） |

**2. 精确（PRECISE）**

无模糊或主观术语。两个不同的人阅读该指令会有相同理解。

| 等级 | 示例 |
|-------|---------|
| 通过 | “将超过 12 个月的竞业禁止条款标记为高风险” |
| 失败 | “分析要更彻底” |
| 失败 | “让它对客户更合适” |

**3. 原子性（ATOMIC）**

一条指令解决单一要求。多项检查应拆分为独立指令。

| 等级 | 示例 |
|-------|---------|
| 通过 | “检查管辖法律条款” |
| 失败 | “检查管辖法律、管辖权和仲裁条款”（三项检查——拆分它们） |

**4. 稳定（STABLE）**

若引用法规或标准，指定版本或日期。指令应在任何时间阅读时以相同方式可评估。

| 等级 | 示例 |
|-------|---------|
| 通过 | “按我们内部政策 [政策名称和引用，日期为 2024 年 12 月 12 日] 审查终止条款。” |
| 失败 | “遵循最新市场标准”（哪些标准？会随时间变化） |

### 第 4 步：对信号分级

| 满足的标准 | 行动 |
|--------------|--------|
| **全部 4 项标准通过** | 直接添加到技能 |
| **少于 4 项标准** | 请求澄清（参见第 5 步） |

### 第 5 步：请求澄清

当反馈未满足所有标准时，使用 `AskUserQuestion` 工具询问缺失内容：

```
我检测到一条更正，但需要更多信息才能改进技能。

您说："[用户的反馈]"

要创建更清晰的指令，我需要以下信息：

[列出基于失败标准的缺失内容的结构化工具调用]
```

**若用户提供澄清** → 更新指令并继续到第 6 步。

**若用户偏好原始内容** → 以原始指令继续到第 6 步。

### 第 6 步：提议变更

```
--- 学习：[skill-name] ---

拟议新增：

1. "[要添加的确切指令]"
   来源："[对话引文]"

2. "[要添加的确切指令]"
   来源："[对话引文]"

---

应用这些变更？[Y/n]
```

### 第 7 步：若获批准

1. **更新 SKILL.md**
    - 读取 `skills/[skill-name]/SKILL.md`
    - 在适当部分添加每条指令
    - 每条指令必须可独立阅读和应用

2. **更新 `skills/[skill-name]/CHANGELOG.md`**
    - 不存在则创建
    - 在顶部添加新条目：
      ```markdown
      ## [日期（格式："January 7, 2026"）]
      [以自然语言描述变更，1-3 句]
      ```
    - 条目规则：
      - 最新在顶部
      - 最多 1-3 句
      - 自然语言
      - 无 git 引用

### 第 8 步：保存观察

对于无法处理的信号，提供保存选项：

```
保存这些观察供日后审阅？
- "[信号 1]" - 状态：[为何不足]
- "[信号 2]" - 状态：[为何不足]
```

若是，追加到 `skills/[skill-name]/OBSERVATIONS.md`

---

## 次要命令

### self-improve on

1. 运行：
    ```bash
    rm -f ./.disabled
    ```
2. 回复：“Automatic mode enabled.”（自动模式已启用。）

### self-improve off

1. 运行：
    ```bash
    touch ./.disabled
    ```
2. 回复：“Automatic mode disabled.”（自动模式已禁用。）

### self-improve status

检查 `.disabled` 文件是否存在并报告。

## self-improve [skill-name] history

1. 显示 CHANGELOG.md 内容
2. 询问：“Would you like to revert to a previous version?”（您想回退到先前版本吗？）
3. 若是：
    - 更新 `skills/[skill-name]/SKILL.md` 中的适当部分
    - 在 `skills/[skill-name]/CHANGELOG.md` 中添加回滚说明

---

## 示例

### 示例 1：满足所有标准

**用户说：**“Always flag non-compete clauses over 12 months as high risk”（始终将超过 12 个月的竞业禁止条款标记为高风险）

**评估：**
- 完整：是 - 指令完全明确
- 精确：是 - “12 months”和“high risk”清晰
- 原子性：是 - 单一检查
- 稳定：是 - 无时间依赖

**结果：** 直接添加

### 示例 2：缺少标准

**用户说：**“Flag any non-market-standard indemnification clause”（标记任何非市场标准的赔偿条款）

**评估：**
- 完整：否 - “non-market-standard”未定义
- 精确：否 - “market standard”是主观的，因交易类型而异
- 原子性：是 - 单一检查
- 稳定：否 - 市场标准随时间演变

**行动：** 使用 `AskUserQuestion` 工具请求澄清：
```
我检测到一条更正，但需要更多细节。

您说："Flag any non-market-standard indemnification clause"

为使其可操作，您能否指定：
- 什么使赔偿条款成为"非市场标准"？（例如无上限责任、涵盖间接损失、无重大过失例外）

您想提供更多细节，还是按您陈述的方式添加该指令？
```

**若用户澄清：** 更新指令并添加。
**若用户偏好原始内容：** 按原样添加指令。

---

## 重要说明

- 绝不猜测用户的意思 - 不清楚时始终询问
- 绝不从上下文推断要求 - 它们必须明确
- 一条指令 = 一项检查 - 拆分捆绑的反馈
- 少数好的指令优于许多模糊的指令
- CHANGELOG.md 是面向用户的记录