The word “skill” can sound softer than it is.
In practice, a good agent skill is a way to package repeatable work so the agent can follow it and the team can review it. It can include instructions, examples, scripts, checklists, source constraints, validation rules, failure rules, and eval cases.
That makes a skill closer to process infrastructure than clever prompt text.
A skill gives teams a way to move useful practices out of one person’s habits and into a process others can inspect.
At scale, this becomes a portfolio question. Which skills are shared across teams, which are specific to one workflow, who approves changes, which evals prove the skill still works, and which failures trigger a skill update, not another private coaching session?
The useful question is whether the skill makes the work less ambiguous.
What should the agent read? When should it act? What should it verify? What does quality look like? When should it stop? What should it hand back to a human?
If a skill answers those questions, it is doing real engineering work.
Process that agents can follow
Most teams have recurring workflows that live in someone’s habits.
Release notes. Incident summaries. Pull request reviews. Proposal drafts. Data-quality checks. Customer handoff notes. Internal research briefs. Test-plan generation.
The work is repeatable, but the process is often implicit. A senior person knows which source to trust, which format to use, which claims need caveats, and which failure modes should stop the work. The agent does not know any of that unless the process is packaged.
That is where skills help.
Take a release-note skill.
A useful package might include SKILL.md, examples from prior releases, a script that collects merged changes, source rules for issue labels and PR descriptions, customer-facing language guidance, validation checks, and failure conditions that require product-manager review.
It gives reviewers something specific to improve without rewriting the whole workflow.
A useful skill might tell the agent:
- Which files or systems to inspect.
- Which sources are authoritative.
- Which examples to follow.
- Which commands or scripts to run.
- Which checks must pass.
- Which claims need evidence.
- Which outputs are not allowed.
- Which failures require escalation.
That is a checklist the agent can actually use.
It also gives the team a review surface. When the output is weak, the question is no longer “why did the model do that?” The team can inspect the skill. Was the source list incomplete? Was the example misleading? Was the validation step missing? Did the skill fail to tell the agent when to stop? A skill turns some model behavior into editable process.
What a skill is not
It helps to define skills against nearby concepts.
A skill is easy to confuse with prompts, tools, memory, MCP servers, repo instructions, or fine-tuning. The distinction I care about is this: a skill packages a repeatable process the agent can follow and the team can review.
A prompt can give direction. A tool lets the agent do something. MCP can expose tools and context. Memory can preserve facts or preferences. Fine-tuning changes model behavior. Repo instructions set broad operating constraints. A skill is narrower and task-shaped: it tells the agent how to approach a kind of work, what evidence to use, what tools may matter, what quality looks like, and when to stop.
The failure modes are different. If a tool fails, you debug the interface. If memory is stale, you debug source freshness. If a skill produces weak work, you inspect the process it encoded.
That inspection should include stopping rules. Good skills do not only describe how to produce the happy path. They also tell the agent what to do when evidence is missing, sources conflict, a command fails, or the output would require a claim the sources do not support.
Those stopping rules are often where a skill becomes valuable. A weak instruction tells the agent to “write a good summary.” A useful skill says which sources count, which claims need evidence, which phrases to avoid, when to mark uncertainty, and when to return a blocker instead of filling the gap.
Review skills like process assets
Skills should be versioned, reviewed, and evaluated.
That may sound heavy for a Markdown file, but the team is encoding how work gets done. If a skill tells an agent how to summarize incidents, check compliance language, or prepare release notes, it can shape decisions and artifacts that other people trust.
The release-note skill should have an eval. Give it a few old releases, known edge cases, and examples where the right answer is to ask for human review. If the skill cannot handle those cases, the team has learned something before the process spreads.
Versioning matters too. When a skill changes, reviewers should know what changed: a source rule, an example, a script, a validation check, or a failure rule. Otherwise teams cannot tell whether better output came from a better model, a better skill, or luck.
Skills can turn recurring work into process infrastructure that agents and humans inspect together.
Before creating another prompt snippet, ask which recurring workflow on your team still lives in one person’s habits and should become reusable process infrastructure. Here are five ways to start.
A few things to try
- Capture one recurring workflow. Choose work that a senior person performs repeatedly and write down the sources, decisions, checks, and handoffs they use. Start with the real process, including the exceptions people handle informally.
- Define the skill boundary. State what the skill owns and what belongs to a tool, memory, repository instruction, or human decision. A narrow task shape is easier to review and evaluate than a bundle of unrelated responsibilities.
- Add completion and failure rules. Describe what must be true before the work is done, which checks must pass, and when missing evidence or conflicting sources should stop the agent. Include the required escalation target or human decision.
- Build a small eval set. Use a few successful examples, known edge cases, and at least one case where the correct result is to stop or ask for review. Re-run those cases when instructions, scripts, examples, or source rules change.
- Assign version ownership. Put the skill under version control, name who can approve changes, and record whether a revision changed sources, steps, validation, or failure behavior. Treat production failures as candidates for the next eval or skill update.
Which recurring workflow on your team still lives in one person’s habits and should become reusable process infrastructure?