SkillVerdict

Pre-publish checklist

Ten things we look at when we review a skill, with examples from verdicts we have published. Go through them before your users do.

  1. Say what it does and when to use it. The name and description in the frontmatter are what the agent and your users read first. The description should match what the skill really does.
  2. Keep allowed-tools narrow. allowed-tools pre-approves tools. Bash(belt *) lets the agent run any belt command, paid model runs included (we flagged it). Scope it to what the skill needs, such as WebFetch(domain:example.com).
  3. List every script. Name each script in the skill folder and say what it does. A skill that is only instructions is the easiest to trust.
  4. Say what leaves the machine. If a command uploads files, say which ones. A cloud render that uploads the whole project, assets included, is something users want to know before they run it (example).
  5. Give prices or a cap for paid calls. If the skill starts paid runs, state the prices or offer a spending limit. media-use refuses any paid call that would go past a credit limit you set, although it tells the agent never to mention prices.
  6. Tell users how to keep their accounts safe. A browser skill should say to use a throwaway profile, not the everyday logged-in one (agent-browser).
  7. Ship a license. A LICENSE file in the repo, and in the skill folder too if people copy the folder on its own.
  8. Give an install command that works. It must match your repo path and folder name. We check it against your README and SKILL.md.
  9. Credit what you adapted. If you started from someone else's skill, link the original and keep its license. We measure similarity: one copy we reviewed was 96.1% the same as its original (case).
  10. Date your changes. A changelog or tagged releases show users and reviewers what changed since the last check.

Want a second reader?

The fast-track review (€49) reads your skill with our method, this list included. You get the findings in private first and 7 days to fix them before the verdict goes live. The verdict can go either way.