I have been thinking about Agent Skills less as a feature and more as training material.
Not training in the model-training sense. Training in the human sense: here is how this work is done here, with these tools, these constraints, these habits, and these review points.
That distinction matters because a lot of agent work still starts from a strange expectation. We ask the agent to understand the task, infer the process, remember the standards, choose the tools, avoid the traps, match the voice, verify the result, and package the output correctly.
Sometimes it works. Sometimes it produces something polished and wrong.
The issue is not always intelligence. Often, the issue is missing operating context.
Coffee is a workflow too
Take something simple: making coffee.
If I ask someone to make coffee without any context, they may still produce coffee. But the result depends on what they assume.
They might use a different method. They might use too much coffee or too little. They might ignore the machine sitting on the counter. They might not know whether I prefer it strong, clean, slow, bitter, filtered, or just fast. They might clean up after themselves, or they might leave the whole process half done.
The task sounds simple because the outcome is familiar. The quality comes from the process around it.
A good barista is not just “better at coffee” in the abstract. They know the equipment, the recipe, the timing, the taste, the expected finish, and the small checks that keep the result consistent.
That is close to how I now think about agent work.
A prompt can ask for the coffee. A workflow explains how this coffee should be made.
The same thing happens in software teams
Software development makes the point even clearer.
A new developer can be smart and still create rework in their first weeks. They can write code, but without team context they may follow the wrong architecture style, skip the test pattern, miss a security rule, branch from the wrong base, duplicate an existing component, or open a pull request that reviewers have to untangle.
The problem is not that the developer is incapable. The problem is that capability without context is expensive.
Good teams solve this with onboarding, documentation, examples, code review, conventions, runbooks, and senior people who correct the early mistakes. Over time, the developer learns how work moves through that environment.
Agents need a version of that.
Not because they are people. Because they are being asked to operate inside real processes.
If an agent writes a blog post, the work is not only the prose. It needs the content schema, frontmatter, image conventions, privacy boundaries, tone, build command, PR format, issue update, and a clear stop before publishing.
If an agent reviews analytics, the work is not only summarizing numbers. It needs to know which signals matter, which samples are too small, what private data must stay out of public writing, and when to create follow-up work instead of making claims.
That is where Agent Skills become interesting.
A skill is an operating layer
An Agent Skill, or what I prefer to call an AI Workflow, is a way to load the right process at the right moment.
It can define:
- when the workflow should be used;
- what context matters;
- which tools are allowed or preferred;
- which steps should happen first;
- what patterns have worked before;
- what mistakes to avoid;
- what the output should include;
- what must be verified before the agent stops.
This is different from making one giant prompt that tries to contain everything.
The agent does not need every workflow in its active context all the time. It needs the right workflow when a specific kind of work starts. Writing a personal Journal post, preparing a weekly product review, opening a GitHub PR, creating a social image, triaging issues, and scanning a public page for sensitive detail are different jobs. They should not all rely on the same vague instruction to “be helpful.”
A skill gives the agent a smaller, sharper operating frame.
It says: for this kind of work, behave like this.
The example I keep returning to
One public-safe example is a weekly product and growth review.
Imagine the agent has access to a PostHog-style analytics source, Search Console context when available, and a set of product goals. Without a workflow, it may produce a generic summary: traffic went up, traffic went down, users clicked this, sessions looked like that.
That is not enough.
A useful review skill would tell the agent what the review is for.
The trigger could be simple: use this when running a weekly product or growth review.
The inputs could be analytics, search context, known goals, and previous decisions.
The review sections might be:
- reliability;
- UX and session friction;
- growth and activation;
- decisions from the week;
- next steps.
The process would matter more than the vocabulary. First check reliability and exceptions. Then inspect UX friction. Then review acquisition-to-activation signals. Then identify one priority bug, one UX opportunity, and one growth hypothesis. Then write a concise Markdown report. Then create follow-up work only when there is enough evidence.
The verification step is the part I care about most.
The skill should remind the agent to distinguish missing data from positive results. It should avoid overclaiming from small samples. It should keep private analytics, internal dashboards, raw sessions, commercial details, and user data out of public writing. It should say when the evidence is weak.
That last sentence is important.
A useful agent is not the one that always finds a confident recommendation. Sometimes the best output is: the data is too thin, do not make a decision yet.
Skills make agents less theatrical
I like this framing because it pushes agent work away from personality and toward process.
The agent does not need to sound wise. It needs to follow the route.
For me, that route usually includes a source of truth, a bounded task, repository or note context, explicit risk rules, a draft artifact, validation, and a handoff point where I make the decision.
That is why I am cautious with agent autonomy as a broad idea. Autonomy without workflow can become noise at scale. The agent starts moving, but the work is hard to inspect, hard to reproduce, and hard to trust.
A skill changes the question.
Instead of asking, “Can the agent do this?” I can ask:
- What context does this process require?
- Which tools should it use?
- What should it never touch?
- What evidence should it collect?
- What output is reviewable?
- Where should it stop?
Those are better questions for real work.
They are also the questions teams already ask when they document a process for humans.
Explore, but do not copy blindly
There is already an ecosystem forming around this idea. A useful place to look is skills.sh, which collects examples of skills and workflows people can explore.
I would not treat any public skill as something to copy blindly into a production process. The value is in seeing the pattern: a skill carries instructions, tool preferences, standards, routes, pitfalls, and expected outputs.
The useful work is adapting that pattern to your own environment.
A content workflow for my personal site has different boundaries than a product analytics workflow. A code review skill needs different failure rules than a LinkedIn image skill. A finance or data workflow needs stricter privacy and evidence checks than a light editorial task.
The shape is reusable. The judgment is local.
Predictability is the product
The more I use agents in actual work, the less interested I am in the magical version.
I do not want an agent that wakes up and invents a strategy. I want an agent that can enter a known workflow, load the right context, do a bounded piece of work, run the checks, and hand me something I can review.
That is less glamorous. It is also more useful.
Agent Skills are not just prompt snippets. They are process memory. They are how an agent learns the difference between a generic answer and the way a specific kind of work should move through a specific operating system.
Coffee needs a recipe. Developers need onboarding. Teams need conventions.
Agents need workflows.
That is the layer I expect to matter more over time: not bigger prompts, not more theatrical autonomy, but better training material for repeatable work.
The output becomes more predictable because the process becomes more explicit.