A skill is a runbook we write by hand and ask a model to load later, which is a weird setup when the instructions can go stale and the model can route to the wrong ones.
Skills are still useful because models can't reliably work out a safe action from a raw tool surface and whatever state happens to be visible. Curated instructions give the agent a path through the system, provided somebody keeps that path current.
Decide what owns the truth
Live discovery and a fixed surface can each make sense, while skills sit awkwardly between them.
Live discovery
The agent reads the current schemas, permissions, documentation, and system state before it acts.
Flexible and current, as long as the underlying sources are good.
Fixed surface
The agent is handed a defined set of capabilities and rules ahead of time.
Predictable and much easier to audit.
The procedure sits in a static document while a router decides at runtime whether to load it, so freshness and selection fail separately and neither layer knows when the other one got it wrong.
Similar can still be wrong
Say a command-line tool adds a required profile flag, and an older skill still shows the command without it.
Routing can work perfectly, retrieve the right document, and still send the action to the wrong default when the agent follows that document to the letter.
Similarity can find the relevant instruction without making it current. A person might notice that a runbook looks off, but an agent usually treats a retrieved skill as operating context, so stale text can turn a bad premise into an action that looks right long enough to survive review.
Somebody has to own the docs
A skill library is ordinary knowledge-management work, with someone deciding whether a capability needs one document or three and updating the examples when the CLI changes.
The same descriptions also end up serving different readers: a person needs to understand the promise, the router needs a clean signal to match on, and the model needs precise operating instructions once loaded. Language that helps one reader can work against another.
If nobody owns that work, the library slowly becomes a collection of confident historical notes, official-looking long after the world they describe has moved on.
Keep changing facts out of the skill
The facts that change belong in sources the agent can query, which means the current schema, the installed version, the permissions, and the present state of the system. What stays stable belongs in the skill, the procedure and the judgment calls that decide when to stop.
The more damage a skill can do, the more boring it should be. Production changes should need explicit authority, and money or outbound messages should need confirmation. A fuzzy match should never be the thing that grants either.
I treat a skill like a runbook that fuzzy matching can find, while current evidence and explicit authority still decide what it can do.
Where this stands
Skills are useful when they hold the procedure and stop conditions without owning live facts or authority, which still have to come from the system's current state.
- A skill format that binds instructions to the live tool version, so stale steps fail loudly instead of silently.
- Evidence that routing plus static docs beats live discovery on freshness, not just on latency.