A skill is a process, so reading it proves nothing. Run it.

/test-a-skill <skill> puts the skill in front of agents that have never seen it, on work you would really bring to it. What they produce shows whether it works. What they had to guess shows what to fix — that is the deliverable.

1. Pick three realistic scenarios

Three inputs you would genuinely hand this skill, spread across the range you would genuinely use it on. Let them differ the way real work differs: in size, in subject, in how much explaining material happens to come with them. Three similar inputs test one thing three times.

Realistic beats adversarial. A pathological input tells you how the skill behaves somewhere it will never go, then tempts you to spend the skill's words fixing that instead of the path every run takes.

Done when each subject is work you would actually bring to this skill, and no two are alike.

2. Run it cold

Pin the skill first — a copy, or a fixed commit. The working tree moves under a long run: another session switches branch and the folder is gone mid-flight.

Then one agent per subject, in parallel, on your strongest model, as a dynamic workflow. Keep the whole fan-out in that one script: its agents are given no Agent or Workflow tool of their own, so a script that expects them to spawn anything quietly comes back empty. Where you are already inside a workflow, spawn claude -p headless instead.

Give each agent a schema, so the gap reports arrive structured rather than parsed out of prose. Give each one the tools it needs rather than only a directory: a permission wall reads back as a defect in the skill, in every report at once.