Does this skill earn its place? — audit card · Resource

Open one skill beside this card. One skill, not the whole folder: the audit only works when you can point at the instructions, the description and the scripts while you read. The blocks run in the order the work does.

1. The skill, and what a good run of it looks like

Do this before you open the instructions, or the file will define "good" for you and you will agree with it.

The skill: ______ What it produces: ______ Last run: ______

"Done well" means: ______

[ ] Name one skill and open its folder, so every item below is checked against the file, not your memory of it.
[ ] Write in one sentence what a good run produces, as an object: a named file or a set of slides.
[ ] List what you fix by hand after every run. That list is the audit's agenda.
[ ] Note when you last ran it. A skill you have not reached for in weeks belongs in block seven.

You cannot audit a skill until you have written down what a good run of it produces.

2. Work this skill re-solves on every run

Watch for the assistant writing the same script twice: the styling routine, the cleanup pass. Rebuilt from scratch each run, it drifts, and you pay for it twice.

[ ] Read the last few runs and name the part that gets rebuilt rather than reused.
[ ] Check whether the skill folder has a scripts directory at all. Plenty that need one have never had one.
[ ] Take a run whose output you liked, and tell the assistant to save the script it used into that folder.
[ ] Name the file after the job it does, so the instruction that calls it reads plainly.
[ ] Add a line to the instructions naming that file and when to execute it. A saved script the instructions never mention never runs.
[ ] Run the same type of task twice and compare the parts you care about: formatting, structure, numbers.
[ ] Read the run log and confirm the saved file was executed. If the assistant wrote fresh code instead, the instruction is not explicit enough yet.
[ ] Let the prose around the output keep varying between runs. What had to stop being a fresh guess is the load-bearing part.

A script that lives only in the conversation is a script you will pay for again tomorrow.

3. The description, and whether the assistant can find the skill

At the start of a session the assistant reads only each skill's name and description, and opens the instructions when a request matches. Everything rests on two lines you probably wrote in a hurry.

[ ] Read the description aloud and check it answers both halves: what job this skill does, and when it should fire.
[ ] Rewrite it in the words someone would actually use when asking for this, not the words you used when you named the folder.
[ ] List every other skill whose description could match the same request, then change one of the pair until the overlap is gone.

Three prompts: obvious ______ reworded ______ must not fire ______

[ ] Fire an obvious request that should reach this skill, and confirm it does.
[ ] Fire the same request in different words, with none of the terms from the description, and confirm it still lands.
[ ] Fire a neighbouring request that this skill must not answer, and confirm it stays closed.
[ ] Leave every description that already routes correctly untouched. Rewriting working descriptions is how a working setup breaks.

A skill the assistant cannot find at the moment you need it is a skill you do not have.

4. Where this skill's corrections live

Skills hold procedural knowledge: how this job gets done. They are not a record of your conversations, so nothing you said in a closed session is in there. Saying "fix it" repairs one artefact and leaves the process as broken as it was.

[ ] Recall the last few corrections you gave this skill, then search the folder for each one. Anything not written down is not in effect.
[ ] If the process itself was wrong, edit the instructions and say what the run should do instead.
[ ] If the output was competent but missed your voice, your brand or your examples, add a reference file and point the instructions at it.
[ ] If the same mistake keeps returning, write an explicit rule that forbids it, naming the thing you do not want.
[ ] Rerun the same task after each edit and confirm the fix held. An untested correction is a correction you hope happened.
[ ] When the assistant reports it cannot find a file you know exists, make it show where it searched before you hand over the path, then fix the routing.

Every correction you make is either written into the folder or thrown away with the session.

5. What the skill checks before it hands anything over

This is the block I would install first. The skill reports done, you open the file, and the formatting is broken or the claims are unsupported or the copy is flat for its reader. You already know how to check that, because you do it by hand every run.

[ ] Write down the manual check you currently perform on this skill's output. That check is the one to move inside the skill.
[ ] For slides or a document, have the skill render each page as an image, inspect the screenshots, fix anything cropped or unreadable, and render again.
[ ] For research and anything with claims in it, have the skill open the primary sources, match each claim to the evidence, and delete what it could not verify.
[ ] For subjective work, have sub-agent personas review it: a beginner reporting where they got lost, a sceptical buyer reporting what they do not believe, someone from your audience reporting where they would click away.
[ ] Confirm the evidence comes from outside the first draft. A model rereading its own draft and pronouncing it good is not verification.
[ ] Tell the skill to keep the issues that appear more than once and revise on those. A skill that applies every note comes back worse than the draft.
[ ] Paste this into the instructions, above whatever the skill does last:

Before returning anything, define the acceptance criteria for this output. Produce the first version, inspect it using the relevant verification method, fix every issue you find, then run another pass. Return the output only once it meets the criteria, with a short summary of what you checked. If something could not be verified, say exactly what remains.

[ ] Confirm the checking happens before the file reaches you, rather than as a section of the report you read afterwards.

Your first look at the output should be the skill's fourth or fifth, not its first.

6. Whether the skill survives leaving home

Agent skills are an open format, so the same folder runs across compatible harnesses. Running it elsewhere is a test, not a migration: everything your setup supplies silently shows up as a failure.

[ ] Copy the folder to another compatible agent and run the same task you used in block two.
[ ] Put the two outputs side by side and list every place the away run fell apart.
[ ] Sort each failure into one of three causes: an assumption about the environment, a missing example of good output, or phrasing that only one model reads the way you meant.
[ ] Replace implied locations with named paths and named files, including the ones that feel too obvious to write.
[ ] Add one example of a good output to the folder wherever wording alone did not carry the point.
[ ] Run it again in both places and confirm you fixed the skill rather than the one output.
[ ] Expect nothing here to close a capability gap. No instruction makes a weaker model behave like a stronger one; what travels is the process.

Run a skill somewhere else and it will hand you the assumptions you never wrote down.

7. When the answer is retire or split, not patch

Some of what this audit turns up is not a repair job. Read these before you spend an afternoon improving something you should delete.

[ ] Retire it if you have not run it since you wrote it and cannot name the next occasion you would.
[ ] Split it if the description covers two jobs, because no single description can name a trigger for both.
[ ] Split it if two skills keep competing for the same request and neither of them is wrong to want it.
[ ] Where two skills do the same job, keep the one carrying saved scripts and written corrections, and delete the other.
[ ] Rewrite rather than patch when the instructions are mostly corrections aimed at a workflow you have stopped using.
[ ] Lift the scripts and reference files out before you delete anything. Those are the parts you paid for; instructions you can write again in an afternoon.

A folder full of skills you never run taxes you every time you go looking for one you do.

After the audit

An unticked box on this card rarely stops your work today. It comes back in a fortnight: as a skill that wrote the same script from scratch again, as a request that landed in the neighbouring skill, or as a result that looked finished right up until you opened it. When that happens, go back to the block the box came from rather than fixing the symptom in front of you.

The principle I take from all of this is that a general-purpose agent becomes your agent only once you write your own work down and then keep correcting that record after every run that disappoints you. If the only blocks you clear today are the first and the fifth, your first look at the output will already have stopped being the agent's first look.