Skill Improver

Improve skills by tracking what works, what you override, and what falls flat — then proposing targeted edits.

Scope

Builder skills — CREATE content or implement changes:

Improve: process (steps that produce weak output), handoffs (gaps between skills, e.g. copywriter → website-expert), output quality (templates, principles, defaults that aren't working), missing guidance.

Evaluator skills — JUDGE content or gate publishing:

Improve: grading criteria (A-D thresholds too strict, too lenient, or missing), checklists, priority definitions (P0/P1/P2), gate logic (what blocks publishing vs. what's a note).

Process

1. Collect Signals

Ask: "Any specific feedback on these skills, or should I work from what I've observed?"

Accept:

• Explicit feedback — complaints ("copywriter keeps writing generic hooks", "voice-guardian flags too many things"), missing checks ("web-content-optimizer doesn't catch X"), grade disagreements ("that should have been a B, not a C")
• Overrides observed in the conversation — output the user rewrote or always edits, steps skipped or reordered, flags the user kept anyway, shipping despite a failing grade. For evaluators this is the strongest signal: the evaluator was wrong, not the user.
• "Just check" — work from observed patterns only

2. Read Target Skill File(s)

Read .claude/skills/<name>/SKILL.md for each target. Note process steps, principles, templates, and output formats. For evaluators, focus on grade definitions, checklist items, priority definitions, and pass/fail thresholds.

3. Diagnose and Propose

Classify each gap.

Builder gap types: missing guidance, weak principle, stale example, missing step, wrong priority.

Evaluator gap types:

For each gap, propose ONE specific edit:

Rules:

• One gap = one proposal. No bundling.
• Additive preferred over rewrites — add a principle, don't rewrite a section. Never remove existing guidance unless it's clearly wrong.
• If a rewrite IS needed, show full before/after. For grading criteria, show the full grade definition before/after. For checklist additions, show where in the list it goes.

4. Get Approval

Present all proposals. User approves, rejects, or modifies each one individually. Never apply without explicit approval.

5. Apply and Log

For each approved edit:

1. Apply the change to the skill file
2. Append to the skill's Change Log (create if missing):

Principles

• Minimal edits — smallest change that addresses the gap
• Your overrides are data — when you consistently keep or redo something, the skill needs recalibration, not you
• One edit, one reason — every change maps to an observed pattern
• Preserve voice — edit the skill's process, not its personality
• User decides — propose, never auto-apply

Evaluator calibration:

• False positives erode trust — an evaluator that flags too much gets ignored. Fewer, higher-confidence flags > many weak flags.
• Evaluators should agree — if voice-guardian gives an A to copy the user keeps rewriting, something is miscalibrated.
• Grade inflation awareness — if everything gets A, the grading is too lenient. If real-world results don't match the grades, someone should have caught it.
• Evaluators flag, don't fix — evaluators identify problems; builder skills fix them. An evaluator prescribing solutions is scope creep.