TL;DR
- A skill can be invoked explicitly or selected by the model from context. Claude Code supports both: users can call a skill directly, while Claude can also use a skill when it judges it relevant. Skill authors can prevent automatic model invocation where a manual trigger is more appropriate.
- Natural-language triggers reduce friction. Explicit skill names narrow the instruction and leave a clearer record of what was requested.
- The question is not which style is more advanced. It is how much ambiguity a workflow can safely absorb before the agent acts.
- A personal log can tolerate a bad guess. A repository, customer workflow, credential, payment or deployment usually needs a visible handle and, often, an approval step.
- Neither side in the exchange offers comparative evidence that one invocation style is generally more reliable. They are describing working systems and different design instincts.
In plain English
A skill is a packaged set of instructions that an AI assistant can load for recurring work: a house style, a deployment procedure, a research method, a review checklist, or a way of writing a daily log.
Instead of explaining the procedure every time, I can give the assistant access to the skill and let it apply the relevant instructions.
There are two broad ways that can happen.
- Explicit invocation: I name the procedure. That might be
/deploy, “use the review skill”, or an instruction inside another skill to call a particular skill by name. - Contextual triggering: I describe what I want in ordinary language, and the agent decides which skill, if any, applies. “Let’s talk about this” may load a discussion skill. “Ship it” may call a release workflow when used in the right project.
Claude Code is designed to support both. Its documentation says that users can invoke skills directly and that Claude can use skills when relevant; it also provides a way to disable model invocation for skills that should only be run deliberately.
The mechanism is straightforward. The interface decision is not.
“Ship it” is an attractive interface for a workflow that pushes code, prepares publication processes and begins a series of reviews. It is also a compressed instruction carrying a surprising amount of assumed context: which repository, which branch, which checks, which publishing path, which approval boundary, and what “ship” means today rather than last month.
That is the useful tension in a recent exchange between Matt Pocock and Daniel Miessler about skills. Pocock shared a practical prompt for getting one Claude skill to invoke another: Call the Skill tool with skill-name. Miessler replied that the best way to invoke a skill is not to name it at all. In a well-built environment, he argued, you should be able to work in natural language and have the right things happen around you.
Pocock’s answer supplied the necessary counterweight. He prefers to optimise his work around the technology available now, rather than technology promised in the future. Miessler agreed there should be a mix, while arguing that the tension should pull towards what is possible: good triggers can make a workflow sound like natural language.
I think the exchange is useful because it is not really about whether either man knows how to call a skill. It is about where an agent should be allowed to infer intent, where it should wait to be told, and what happens when an apparently simple phrase starts real work.
The useful future, and the useful present
Miessler’s ambition is right. Software has spent decades making users learn its internal map: which menu holds the setting, which app owns the record, which command changes the thing, which system uses which vocabulary. An assistant that can recognise intent and remove that translation work is doing something valuable.
That matters for accessibility as much as convenience. For some people, the extra step of remembering a command, choosing from a menu, or translating a thought into the software’s preferred words is the point at which the work stops. If “log that” gets the thought out of someone’s head and into a useful place, the interface has done its job.
Pocock’s point matters just as much. A future in which context, memory and intent resolution work reliably does not mean an explicit command is a failure in the present. A working procedure with a clear name is not crude because an eventual system may infer the same procedure from a sentence.
YAGNI — “You Aren’t Gonna Need It” — is a useful warning here. There is little sense building layers of implicit triggering merely to avoid a clear instruction that already works. In the language of the thread, this may be ATD: Ain’t That Different. The user can say a natural phrase; the user can name a skill. The important question is what changes when the system makes the choice instead.
Where the ambiguity goes
A natural-language trigger does not eliminate ambiguity. It moves it.
With one well-described skill, “let’s talk about this” may be a good enough match. Add research, planning, editing, writing, project management, client-specific procedures and project-level context, and the phrase becomes a retrieval query. Which skill should win? Should several load? Should the assistant ask? Should it infer from recent files, the current repository, a memory system, or the name of the current project?
Jay Dev put the problem neatly in a reply to the thread: implicit triggers make for cleaner UX, but move the collision problem onto skill descriptions rather than exact names. That is exactly right. The ambiguity is no longer in the user’s command. It is in the metadata, descriptions, priority rules, loaded context, and model judgement that decide what the words mean here.
That may be a sensible trade. It may be the right trade in a small, well-understood environment built by one person for their own work. It gets harder as the skill library expands, the workflows acquire more consequences, or someone else needs to understand and operate the system.
Leit Motif made the philosophical version of the same point: alignment follows articulation, which follows understanding. A conversational trigger only feels effortless when the person and system share enough context to mean the same thing by it.
Consequence decides the default
I use both styles. What determines the choice is not whether I like commands or magic on a particular day. It is what the skill can do when it fires.
For a daily note or project log, I generally want the agent to infer. I say what happened, it writes the entry, and I do not need to think about the internal procedure. The result is easy to inspect, cheap to correct and reversible. If it selects the wrong skill, I have probably lost a minute.
For technical work, I am more likely to name the skill. When a procedure can touch a repository, a deployment, a credential, a production service, a customer record, a payment or public-facing material, I want to state the process I am authorising. Naming it is not more virtuous. It is a narrower instruction and a useful record of intent.
| What the skill can do | Sensible default | Why |
|---|---|---|
| Capture a private note or personal log | Contextual triggering | Mistakes are cheap, visible and easy to correct |
| Prepare a draft or apply a writing style | Usually contextual, with review | The work is bounded, but output still needs checking |
| Change code, create branches or alter infrastructure | Explicit invocation, then confirmation where appropriate | Technical blast radius and recovery cost rise quickly |
| Send messages, publish material or change customer and financial records | Explicit invocation plus an approval gate | The system should not infer authority to make an external commitment |
| Retrieve sensitive data or use credentials | Explicit invocation with least privilege | The access path itself carries risk |
This is familiar territory in security engineering. Authority should be proportionate to consequence, constrained to the task, and visible to the person granting it. Agent skills deserve the same treatment.
An assistant can reasonably infer that I would like help. It needs a stronger basis before it infers that I want it to act.
The two ways it goes wrong
The successful case for contextual triggering is easy to picture. I describe an outcome, the right procedure runs, and the machinery disappears.
The failures show what the interface is actually buying.
Lately, including today, agents and skills I run have second-guessed me: checking things I did not ask them to check, following paths I did not need, and turning a bounded request into a small investigation. This is one person’s recent experience, not measured evidence about agent behaviour in general. I am not presenting it as more than that.
It does identify a real cost, though. When a system interprets intent, it can interpret more intent than I supplied. “Have a look at this” can become an unrequested audit. The work may be competent. It can still be the wrong work.
The opposite error is quieter. I have a standing rule that anything I am going to read and review should go to Drafts, where it appears on my phone, rather than sitting in a repository or vault. The rule is written down in my instructions. It was available. An assistant nevertheless wrote an article directly into the site repository and handed me a file path. I had to stop it and specify the process: this belongs in Drafts for review.
One day the agent sees a workflow that was not there. Another day it fails to see the workflow that was. The source is the same: it is choosing the procedure rather than receiving an unambiguous instruction to use it.
The point is not to ban inference. It is to be honest about the trade. Delegating interpretation reduces interface work for the user. It also makes the quality of the agent’s interpretation part of the workflow’s reliability.
Keep the handle
A named skill does not prove that the instructions were sensible, the right tools were used, or the result was correct. It does establish a boundary: this is the procedure I asked for.
That matters when work needs to be explained, handed to a colleague, reproduced somewhere else or investigated after a failure. If no one names the skill, the account of what happened can live only in the agent’s selection logic and execution trace. That may be enough for a private, reversible task. It is a thin record for a system other people must operate or trust.
This is why I do not think explicit invocation is an early stage of a workflow that should disappear as the technology improves. It is one control surface among several. A good agent interface should let a person use ordinary language when that is the easiest and most accessible way to work. It should also let that person point to a named procedure, understand what it will do, and require a deliberate approval before it does something consequential.
A system that supports only ambient interaction has decided that every user should supply context in the same way and accept the same level of inference. A system that requires every user to memorise commands has made a different, equally narrow choice. Neither is the promised technology meeting people where they are.
I want the future Miessler describes: software that understands enough of my work that I do not have to translate every intention into a command. I also want Pocock’s discipline: build around what works, do not create inference machinery merely to avoid a clear instruction, and do not mistake a smooth demo for a solved operational problem.
The practical rule is simple. Decide where ambiguity belongs. A personal log can absorb it. A deployment, customer workflow, credentialed system or public publication usually cannot.
The magic in agent interfaces is real. I just want an off switch, and a handle on the machinery, before it does work in my name.