skill-optimizer-lawvable
- Repo stars 366
- Author updated Live
- Author repo awesome-legal-skills
- Domain
- Engineering
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @lawve-ai · no license declared
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: skill-optimizer-lawvable
description: Guide to analyze a current work session and propose improvements to skills. Use (1) automaticall…
category: engineering
runtime: no special runtime
---
# skill-optimizer-lawvable output preview
## PART A: Task fit
- Use case: Guide to analyze a current work session and propose improvements to skills. Use (1) automatically after working with a skill to capture learnings, (2) when the user suggests improvements, corrections, or additions during a skill-related session, or (3) when the user manually invokes `self-improve`..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Triggers / Main Workflow (self-improve) / Step 1: Identify the Skill” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Guide to analyze a current work session and propose improvements to skills. Use (1) automatically after working with a skill to capture learnings, (2) when the user suggests improvements, corrections, or additions during a skill-related session, or (3) when the user manually invokes `self-improve`.”.
- **02** When the source has headings, the agent prioritizes “Triggers / Main Workflow (self-improve) / Step 1: Identify the Skill” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “Triggers / Main Workflow (self-improve) / Step 1: Identify the Skill”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: skill-optimizer-lawvable
description: Guide to analyze a current work session and propose improvements to skills. Use (1) automaticall…
category: engineering
source: lawve-ai/awesome-legal-skills
---
# skill-optimizer-lawvable
## When to use
- Guide to analyze a current work session and propose improvements to skills. Use (1) automatically after working with a…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Triggers / Main Workflow (self-improve) / Step 1: Identify the Skill” and keep inference separate from source facts.
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "skill-optimizer-lawvable" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Triggers / Main Workflow (self-improve) / Step 1: Identify the Skill
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} Self-Improve Skill
Analyze the current conversation and propose improvements to skills based on corrections, successes, and edge cases discovered during the work session.
Triggers
self-improve- Analyze session and propose improvementsself-improve [skill-name]- Target a specific skillself-improve on- Enable automatic mode (hook)self-improve off- Disable automatic modeself-improve status- Show automatic mode statusself-improve [skill-name] history- Show modification history
Main Workflow (self-improve)
Step 1: Identify the Skill
If skill name not provided, list available skills from skills/ directory and ask:
Which skill should I analyze for this session?
[List skills found in skills/ directory]
Step 2: Detect Signals
Scan the conversation for signals - moments where the user expressed feedback:
| Signal Type | Examples |
|---|---|
| Correction | "No", "That's not right", "It's missing X", "Always do Y", user rewrites output |
| Success | "Perfect", "Yes", "Exactly", user accepts without changes |
| Edge case | User needed a workaround, skill couldn't handle the request |
Step 3: Evaluate Each Signal for Quality
For each correction signal, evaluate if it can become a good skill instruction.
Quality Criteria
1. COMPLETE
The instruction includes all information needed to apply it. No need to look elsewhere or make assumptions.
| Grade | Example |
|---|---|
| Pass | "Structure output as: Key Terms / Risk Areas / Suggested Revisions" |
| Fail | "Use the standard format" (which format?) |
| Fail | "Follow our firm's guidelines" (what guidelines?) |
2. PRECISE
No vague or subjective terms. Two different people reading the instruction would understand it the same way.
| Grade | Example |
|---|---|
| Pass | "Flag non-compete clauses over 12 months as high risk" |
| Fail | "Be more thorough in the analysis" |
| Fail | "Make it more appropriate for clients" |
3. ATOMIC
One instruction addresses one single requirement. Multiple checks should be split into separate instructions.
| Grade | Example |
|---|---|
| Pass | "Check for governing law clause" |
| Fail | "Check for governing law, jurisdiction, and arbitration clauses" (three checks - split them) |
4. STABLE
If referencing regulations or standards, specify the version or date. The instruction should be evaluable the same way regardless of when it's read.
| Grade | Example |
|---|---|
| Pass | "Review the termination provisions under our internal policy [policy name and reference], dated December 12, 2024." |
| Fail | "Follow latest market standards" (which standards? will change over time) |
Step 4: Grade the Signal
| Criteria Met | Action |
|---|---|
| All 4 criteria pass | Add to skill directly |
| Less than 4 criteria | Ask for clarification (see Step 5) |
Step 5: Ask for Clarification
When feedback doesn't meet all criteria, ask for what's missing using the AskUserQuestion tool:
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]
If the user provides clarification → Update the instruction and proceed to Step 6.
If the user prefers the original → Proceed to Step 6 with the original instruction.
Step 6: Propose Changes
--- 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]
Step 7: If Approved
Update SKILL.md
- Read
skills/[skill-name]/SKILL.md - Add each instruction in the appropriate section
- Each instruction must be readable and applicable on its own
- Read
Update
skills/[skill-name]/CHANGELOG.md- Create if doesn't exist
- Add new entry AT THE TOP:
## [DATE (format: "January 7, 2026")] [Description of changes in natural language, 1-3 sentences] - Entry rules:
- Most recent at top
- 1-3 sentences max
- Natural language
- No git references
Step 8: Save Observations
For signals that couldn't be processed, offer to save:
Save these observations for later review?
- "[signal 1]" - Status: [why insufficient]
- "[signal 2]" - Status: [why insufficient]
If yes, append to skills/[skill-name]/OBSERVATIONS.md
Secondary Commands
self-improve on
- Run:
rm -f ./.disabled - Reply: "Automatic mode enabled."
self-improve off
- Run:
touch ./.disabled - Reply: "Automatic mode disabled."
self-improve status
Check .disabled file existence and report.
self-improve [skill-name] history
- Display CHANGELOG.md content
- Ask: "Would you like to revert to a previous version?"
- If yes:
- update the appropriate sections in
skills/[skill-name]/SKILL.md - update
skills/[skill-name]/CHANGELOG.mdwith a rollback note
- update the appropriate sections in
Examples
Example 1: All criteria met
User said: "Always flag non-compete clauses over 12 months as high risk"
Evaluation:
- Complete: Yes - instruction is fully specified
- Precise: Yes - "12 months" and "high risk" are clear
- Atomic: Yes - single check
- Stable: Yes - no time dependency
Result: Add directly
Example 2: Missing criteria
User said: "Flag any non-market-standard indemnification clause"
Evaluation:
- Complete: No - "non-market-standard" is not defined
- Precise: No - "market standard" is subjective and varies by deal type
- Atomic: Yes - single check
- Stable: No - market standards evolve over time
Action: Ask for clarification using the AskUserQuestion tool:
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?
If user clarifies: Update the instruction and add it. If user prefers the original: Add the instruction as stated.
Important Notes
- Never guess what the user meant - always ask if unclear
- Never infer requirements from context - they must be explicit
- One instruction = one check - split bundled feedback
- Fewer good instructions is better than many vague ones
- CHANGELOG.md is the user-facing record
Decide Fit First
Design Intent
How To Use It
Boundaries And Review