Inputs, checks, negative triggers, and review

Require what you need. A skill missing a critical input should ask one specific question, not proceed on a plausible default. "Which environment?" is a five-second interruption; a deployment checklist silently run against production because the skill assumed the usual one is a different kind of afternoon.

Define what done means. Add objective checks the skill must run before claiming success — the tests pass, the file parses, the output contains the required sections. Without them, "done" is the model's opinion that it has finished, and a skill that reports success it didn't verify is worse than one that reports nothing, because you stop checking.

Test the negative triggers. Write three requests that are similar to your skill's territory but shouldn't activate it, and confirm it stays out. This is the test people skip, and over-triggering is the more common failure in practice: a skill that fires on adjacent questions injects a procedure into conversations that didn't want one.

Change it like code. One behaviour at a time, with a note on why and a before/after test. Skills drift — someone adds a clause to fix one case and three other cases change quietly, because nothing here has a type checker.

A skill you didn't write is code you're choosing to run. Before installing a third-party one, read the instructions it will inject, any scripts it ships, whether it reaches the network, and what permissions it expects. "It's just a markdown file" is wrong twice over: instructions steer a model that has your tools, and a skill directory can carry scripts.

Loading your workspace…