Testing the scripts inside a skill
A skill's scripts run on the buyer's machine with whatever is installed there. Unit-test them, keep dependencies minimal, and fail loudly when one is missing.
Scripts are where skills most often break on someone else's machine, because they touch the real environment. The good news is that they are just code, and code can be tested without a model.
Test them like code
- Unit tests for each script, run in CI on every commit.
- A fixture folder of sample inputs, including a broken one.
- Exit codes that mean something: zero for success, non-zero with a message for failure.
Make dependencies boring
Every third-party package is a way for the first run to fail. Prefer the standard library. When something is required, check for it at the top and say exactly what to install, all at once, rather than failing on the first missing piece. The pattern is in a preflight script.
Then run the whole skill somewhere clean, as in a Docker harness, because unit tests pass on your machine for the same reasons the skill does.
Questions
Should skill scripts have their own tests?
Yes. They are ordinary code that happens to be called by Claude. Test them with ordinary unit tests, separately from any model run.
How do I handle dependencies in skill scripts?
Prefer the standard library, state any requirement in the README and SKILL.md, and check for it at the start of the script with a clear message.
Which language should skill scripts use?
One your users reliably have. Python 3 and shell are common; check the versions you rely on.