Inside Matt Pocock's Skills: Where the Control Lives
A commit-pinned reading of the Matt Pocock Skills repository shows how its invocation rules keep workflow direction with the human while the host retains tools and permissions.
In my earlier article about skills and loops, I explained why I moved away from one prescribed agent workflow. I wanted to choose the smallest process that matched the uncertainty instead of sending every task through the same route.
I was still left with one question: what does a skill actually control?
To answer it, I read Matt Pocock’s Skills repository as a system rather than treating individual SKILL.md files as isolated prompts. A human chooses when to start a major workflow. The agent investigates and executes. The host controls the tools and permissions.
This is a reading of version 1.2.3 at commit 6acc160, not a benchmark across models. The repository changes quickly, so I use that commit as the source of truth throughout.
A skill sets the method; the host sets the limits
The public Agent Skills specification defines a skill as a directory containing at least a SKILL.md. Its frontmatter provides a name and description, while the body gives the procedure. Scripts, references, and assets are optional.
The skill supplies the method. The host supplies capability, and evidence returns the next phase to the human.
Installation only puts those files where a host can discover them. In this snapshot, the repository offers a managed Claude Code plugin or an editable copy installed through skills.sh, and warns against installing both. That choice changes who owns and updates the files. It does not give the skill its own runtime. The installation section of the README makes the distinction clear.
A skill can tell an agent to inspect a diff, run a test, open a browser, or update an issue. It cannot create those capabilities or grant permission to use them. The model loop, shell, browser, sandbox, API credentials, and approval system belong to Claude Code, Codex, or another host. If the host does not expose a tool, the procedure cannot use it. If a write requires approval, a sentence in SKILL.md does not bypass that approval.
The Markdown procedure can travel, but its triggering rules, plugin packaging, permissions, tool names, and model behavior still need host-specific handling. The repository’s Claude and Codex invocation mapping shows that adapter layer. It does not establish that every host behaves identically.
Invocation keeps changes of direction human-gated
The repository divides skills by who may start them.
| Type | Who starts it | Responsibility |
|---|---|---|
| User-invoked | The human | Orchestrate a workflow whose timing or direction matters |
| Model-invoked | The human or model | Apply reusable discipline when the current task matches |
The important distinction is whether a skill changes the route around the task or constrains work already underway. User-invoked skills disable implicit model invocation. Model-invoked skills keep descriptions rich enough for the host to match them to relevant work. A user-invoked workflow may direct the agent to use a model-invoked discipline, but it cannot silently launch another user-invoked workflow. The repository documents those rules in its invocation policy.
TDD or bug diagnosis can apply automatically because they constrain work already underway. Creating a specification, splitting work into tickets, or starting a large planning exercise remains a human choice because it changes the process around the work.
/ask-matt shows the boundary. It is a router over the collection: it explains which route fits, but it does not become an autonomous supervisor that runs every phase.
Artifacts and checks make the method inspectable
The repository moves state into durable artifacts instead of asking the model to remember more. The handoff skill tells an agent to reference existing artifacts and record only the live thread that has not landed elsewhere. A handoff should not copy the specification, ADRs, and diff into another document that can drift.
Because those sources live in files, issues, and Git history, they can be inspected and reviewed without trusting the agent’s account of what happened. They also survive a change of model or host better than conversation state.
Instructions can make a procedure more likely, but they cannot establish that the result is correct. The tdd skill works one vertical slice at a time: agree the public seam, write one failing test, add the minimum implementation, then repeat. The test can disagree with the code, which makes it more useful than an agent saying it followed TDD.
The feedback loops below have different shapes, but each moves from an agent action to a signal that can disagree with it.
Tests, reproducers, and independent review axes turn procedure into something observable.
This is a map, not an autonomous loop
This remains a source reading. It does not show that the skills produce the same behavior across hosts or establish a universal success rate. Their natural-language behavior still has to be observed in a real host and model.
The collection also does not form the outer maintenance loop I described in my earlier article. It does not independently choose the next issue, wake up later, enforce a retry budget, or decide that repeated failure needs escalation. /ask-matt is a map, not a scheduler. The human still owns the major state transitions.
What I am taking forward
Matt Pocock’s Skills put reusable engineering discipline close to the agent without making the agent look autonomous. The host keeps tools and permissions, the human keeps changes of direction, and artifacts and checks keep the work inspectable.
I want each responsibility in the smallest place that can own it: a model-invoked skill for reusable discipline, a human gate for a change of direction, an artifact for durable state, and a feedback loop for claims about correctness.