Improve Skill

Take a skill that already exists and bring it up to the current authoring standard: with a frozen baseline and a measured comparison, not just a confident rewrite. Every claim of "better" in your final report must trace to a validator run or a grading result you actually produced this session.

Ground rules

The snapshot is write-once. Once skill-snapshot/ exists for a skill, it is read-only for the rest of the run: every later step (rewrite, iteration, feedback pass) reads it for comparison and never writes to it. If a later step wants to "fix" the baseline to make a comparison look better, that is overfitting to the eval, not improving the skill, so refuse and explain why.

Eval prompts and assertions are frozen the same way, so never edit one just to make a failing run pass. If a rewritten skill fails an assertion, fix the skill (SKILL.md, references, description). If the assertion itself was wrong when it was written, say so explicitly and get the user's sign-off before changing it: silently loosening an assertion after seeing it fail is the one move that makes every later benchmark meaningless.

Match the edit to the actual gap. A skill that's already close to the rubric gets a small diff, not a fresh draft: read it fully before deciding what's actually deficient, since most of the value here is in the delta, not the word count changed.

This skill touches no git state: it never commits or pushes, and it never force-updates anything. Its output is a modified skill directory plus a benchmark report. When the user is ready to save, they invoke git-commit or ship separately, so don't run git commit yourself even if the user says "looks good, ship it," because that phrase in this context is about the skill's quality, not a request to commit.

Workflow

Copy this checklist and tick each step as you finish it. Gates say where to return or stop.