Open-source meta-skill skill-diet uses evaluation to slim down Agent Skills
The open-source meta-skill skill-diet is used to compress bloated SKILL.md files and check whether tools are outdated. The author @nicopreme measured on real skills that it can reduce tokens by 70–80% with unchanged results. A slimmed-down version is kept only if it is at least on par in same-task evaluations against the old skill, the new skill, and no skill; every subsequent addition must also pass the threshold, and a roughly 10% increase over the previous diet triggers another round. It also places information in layers by skill description, SKILL.md, references/, and tool help and error messages, and recommends leaving mechanical errors to error messages, tests, or linters.
Why read this
AI score 69
The original article presents skill-diet's layered slimming approach and evaluation thresholds, which can be adapted to the maintenance workflow for your own Agent skills.
Topics
View original postI've been dogfooding "skill-diet", a skill for slimming down agent skills and keeping them correct. most skills load far more text than a task needs, and some parts often go stale. it also gets worse over time as AI updates skills. skill-diet cuts what the model already does without being told, moves rarely needed detail into files it only reads when needed, and fixes what no longer matches the tool. then it runs the same tasks with the old skill, the new one and no skill, and keeps the new one only if agents do at least as well. on my own skills: 70–80% fewer tokens, same results. https://t.co/h1BnVt7NjD
View original
I've been dogfooding "skill-diet", a skill for slimming down agent skills and keeping them correct. most skills load far more text than a task needs, and some parts often go stale. it also gets worse over time as AI updates skills. skill-diet cuts what the model already does without being told, moves rarely needed detail into files it only reads when needed, and fixes what no longer matches the tool. then it runs the same tasks with the old skill, the new one and no skill, and keeps the new one only if agents do at least as well. on my own skills: 70–80% fewer tokens, same results. https://t.co/h1BnVt7NjD
Body · AI translation
[Open-source Skills Recommendation] skill-diet: Putting Skills on a Diet — Using Evals to Ensure "Leaner but Not Worse"
skill-diet is a meta-skill that manages other skills: on one hand it slims down bloated SKILL.md files and checks whether tools are outdated, and on the other it sets rules for every subsequent skill change; a slimmed-down version is kept only if it at least doesn't lose in same-task evals of "old skill / new skill / no skill." The author @nicopreme tested it on real skills and found it can cut 70–80% of tokens, and it also surfaced commands in the docs that no longer work. https://t.co/wRktTWUfGg
Every time an agent uses a skill, it reads the entire SKILL.md. Common redundancies include: details most tasks don't need, common knowledge the model already has, explanations written for humans, and long lists that could be replaced by a single principle; skills that teach a CLI/API/SDK/MCP also tend to copy a tool manual, which goes stale as soon as the tool changes. Telling the agent to "update the skill" usually just makes it longer.
It does two things · Put on a diet: rewrite, fix places that don't match the tool; keep the slim version only if it passes evals. · Keep lean: every subsequent addition must first pass a set of gates, so lessons and code changes don't fatten it back up; roughly a 10% growth relative to the last diet triggers another round.
You can just say: put the deploy skill on a diet / is this skill still accurate for the current CLI? / add this lesson to ….
Layering: put facts at the lowest layer that is "just enough" · skill description: one trigger per scenario, in almost every session · SKILL.md: rules needed for almost every task, when the skill is enabled · references/: details only a few tasks need, when that scenario comes up · the tool's built-in help: flags, valid values, examples, when that command is selected · tool responses / errors / checker: correct names, fixes, next steps, when a call fails or guesses wrong
Skills that teach a tool have two more steps: keep exact field names on the tool side; handle mechanical errors preferentially via clearer error messages, tests, or a linter rather than writing another paragraph of prose. Skills that are only manually triggered can be marked user-only, so the description doesn't waste quota every session.
What one diet does Measure size and typical task load → (if teaching a tool) prove skill↔tool mismatches with a run or source lines; find high-frequency calls from session logs and write only the high-frequency ones in full; check whether the agent actually opens the skill, and if it rarely does, push the rules down into tool errors; if necessary, trim your own tool schema (the schema is sent with every request) → cut text the model already knows and text only humans need → run old / new / no skill on the same task; if the slim version isn't better than what "random fluctuation can explain," it fails. Prefer writing commands as usage lines the agent will type (relative costs given by the author: table 1.5×, TS types 1.6×, JSON Schema 2.8×, OpenAPI 4.7×).
For every subsequent skill change: stop at the first step that can handle it · Fix the tool first (error / check), don't pile on prose. · If a new session would get it right without writing it, don't add it. · Edit the existing line, don't start a new paragraph. · Put it at the lowest layer that is still "in time." · Write rules, not stories (stories go in the commit). If code changes a name or behavior the skill depends on, change the skill in the same change; record before/after size in the commit.