mcpField
S
skill-optimizer-lawvable

skill-optimizer-lawvable

github.com/lawve-aiAgent 工作流90783 次安装1 周前更新
代码仓库

关于 skill-optimizer-lawvable

用于自我改进的 Skill,会分析对话中的纠正、成功反馈和边缘情况,并提出对现有 Skill 的精确修改建议。它支持指定 Skill、管理自动模式和查看修改历史。

主要功能

  1. 01识别纠正、成功反馈和边缘情况
  2. 02评估反馈是否适合作为指令
  3. 03提出 Skill 修改建议
  4. 04控制自动模式
  5. 05查看修改历史

适用场景

  1. 01将反复出现的纠正转化为 Skill 规则
  2. 02在遇到边缘情况后审查 Skill
  3. 03查看或回退已记录的修改

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/lawve-ai/awesome-legal-skills --skill skill-optimizer-lawvable

安装后在 Claude Code 中输入/skill-optimizer-lawvable确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

LICENSE.txt
README.md
scripts/
self-improve-hook.sh

详细介绍

自我改进技能

分析当前对话,根据本次工作过程中发现的纠正、成功经验和边缘情况,提出技能改进建议。

触发方式

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

主要工作流(self-improve)

步骤 1:识别技能

如果未提供技能名称,请列出 skills/ 目录中的可用技能并询问:

Which skill should I analyze for this session?
[List skills found in skills/ directory]
步骤 2:检测信号

扫描对话,查找信号——用户表达反馈的时刻:

信号类型示例
纠正“不对”“这不正确”“缺少 X”“始终执行 Y”,用户重写输出
成功“完美”“是的”“正是如此”,用户接受结果且未作修改
边缘情况用户需要变通方法,技能无法处理请求
步骤 3:评估每个信号的质量

对于每个纠正信号,评估它是否能转化为良好的技能指令。

质量标准

1. 完整

指令包含应用所需的全部信息。无需查找其他内容或自行推断。

等级示例
通过“按以下结构组织输出:关键术语 / 风险领域 / 建议修订”
不通过“使用标准格式”(哪种格式?)
不通过“遵循本公司的准则”(哪些准则?)

2. 精确

没有含糊或主观的措辞。不同的人阅读这条指令时,会得出相同的理解。

等级示例
通过“将超过 12 个月的竞业禁止条款标记为高风险”
不通过“分析得更全面一些”
不通过“让内容更适合客户”

3. 原子性

一条指令只针对一个要求。多项检查应拆分为单独的指令。

等级示例
通过“检查是否包含管辖法律条款”
不通过“检查管辖法律、司法管辖权和仲裁条款”(包含三项检查,应拆分)

4. 稳定

如果引用法规或标准,应注明版本或日期。无论何时阅读,都应能以相同方式评估该指令。

等级示例
通过“根据我们的内部政策 [政策名称和参考编号],审查终止条款;该政策日期为 2024 年 12 月 12 日。”
不通过“遵循最新市场标准”(哪些标准?标准会随时间变化)
步骤 4:评定信号
符合的标准操作
全部 4 项标准均通过直接添加到技能中
未达到 4 项标准请求澄清(见步骤 5)
步骤 5:请求澄清

当反馈未达到全部标准时,使用 AskUserQuestion 工具询问缺少的信息:

I detected a correction but need more information to improve the skill.

You said: "[user's feedback]"

To create a clearer instruction, I need the following information: 

[Structured tool call listing what's missing based on failed criteria]

如果用户提供了澄清 → 更新指令并继续执行步骤 6。

如果用户倾向于保留原内容 → 使用原始指令继续执行步骤 6。

步骤 6:提出更改
--- Learning: [skill-name] ---

Proposed additions:

1. "[exact instruction to add]"
   Source: "[quote from conversation]"

2. "[exact instruction to add]"
   Source: "[quote from conversation]"

---

Apply these changes? [Y/n]
步骤 7:如果获得批准
  1. 更新 SKILL.md

    • 读取 skills/[skill-name]/SKILL.md
    • 在适当的部分添加每条指令
    • 每条指令都必须能够独立阅读和应用
  2. 更新 skills/[skill-name]/CHANGELOG.md

    • 如果文件不存在,则创建
    • 在最顶部添加新条目:
      ## [日期(格式:“January 7, 2026”)]
      [用自然语言描述更改,1-3 句话]
      
    • 条目规则:
      • 最新条目置顶
      • 最多 1-3 句话
      • 使用自然语言
      • 不包含 git 引用
步骤 8:保存观察结果

对于无法处理的信号,提出保存建议:

Save these observations for later review?
- "[signal 1]" - Status: [why insufficient]
- "[signal 2]" - Status: [why insufficient]

如果用户同意,则将内容追加到 skills/[skill-name]/OBSERVATIONS.md


次要命令

self-improve on
  1. 运行:
    rm -f ./.disabled
    
  2. 回复:“已启用自动模式。”
self-improve off
  1. 运行:
    touch ./.disabled
    
  2. 回复:“已禁用自动模式。”
self-improve status

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

self-improve [skill-name] history

  1. 显示 CHANGELOG.md 的内容
  2. 询问:“是否要回退到之前的版本?”
  3. 如果是:
    • 更新 skills/[skill-name]/SKILL.md 中相应的部分
    • 在 skills/[skill-name]/CHANGELOG.md 中添加回滚说明

示例

示例 1:满足所有标准

用户说:“始终将超过 12 个月的竞业禁止条款标记为高风险”

评估:

  • 完整:是——指令已完整说明
  • 明确:是——“12 个月”和“高风险”含义清楚
  • 原子化:是——单项检查
  • 稳定:是——不受时间影响

**结果:**直接添加

示例 2:缺少标准

用户说:“标记任何不符合市场标准的赔偿条款”

评估:

  • 完整:否——未定义“不符合市场标准”
  • 明确:否——“市场标准”较为主观,且因交易类型而异
  • 原子化:是——单项检查
  • 稳定:否——市场标准会随时间变化

**操作:**使用 AskUserQuestion 工具请求澄清:

I detected a correction but need more details.

You said: "Flag any non-market-standard indemnification clause"

To make this actionable, can you specify:
- What makes an indemnification clause "non-market-standard"? (e.g., uncapped liability, coverage of indirect damages, no carve-outs for gross negligence)

Do you want to provide more details, or should I add the instruction as you stated it?

**如果用户澄清:**更新该指令并添加。 **如果用户倾向于保留原始表述:**按原样添加该指令。


重要说明

  • 切勿猜测用户的意思——有不清楚之处时务必询问
  • 切勿根据上下文推断要求——要求必须明确提出
  • 一条指令 = 一项检查——拆分捆绑在一起的反馈
  • 少量优质指令胜过大量含糊指令
  • CHANGELOG.md 是面向用户的记录

评论

支持 Markdown