AI agent skills work by giving an agent a reusable procedure for a specific task. The agent discovers a skill from its name and description, loads the instructions when relevant, then uses supporting files or tools to do the work. A skill can teach your preferred process. It does not, by itself, prove the process was followed.
That distinction matters when you are tired of explaining the same job twice. A weekly client report should not require another long chat about headings, missing numbers and which recommendations need review. Those instructions belong in a maintained procedure, not someone's recollection of last Tuesday's prompt.
The useful question is not how many skills your agent has. It is whether one skill turns a recurring job into an output you can accept without redoing the work.
What is an AI agent skill?
An AI agent skill is a package of instructions and optional resources for a defined task. In the Agent Skills open format, that package is a folder containing a required SKILL.md file, with optional scripts, reference documents and templates.
Think of it as an operating procedure the agent can open when needed. A client-reporting skill might contain:
- Instructions for selecting the reporting period and reading approved source records.
- A template with the sections the account manager expects.
- A reference explaining the business's definitions of qualified leads and booked work.
- A small checking script that flags missing required fields.
Those files have different jobs. The instructions explain the sequence. The reference defines terms. The template shapes the deliverable. The script checks something concrete.
This is more specific than asking the agent to “be a great account manager.” It describes what a useful result looks like and what to do when the necessary evidence is absent.
How does an agent find and use a skill?
The standard describes three stages: discovery, activation and execution. The agent sees a short description first, reads the full procedure when the task matches, and accesses additional resources as needed.
This approach is called progressive disclosure: show the index before opening every chapter. Anthropic's engineering explanation shows how skill metadata enters the agent's context before the full instructions and supporting files.
For the reporting example, the sequence would look like this:
- You ask for the weekly client report.
- The agent identifies the reporting skill from its description.
- It reads the procedure and the relevant metric definitions.
- It gathers the approved records and prepares the report.
- It runs the specified checks and presents the result for review.
The last two steps are the workflow you design, not automatic promises of the file format. A skill can describe them clearly and still be used incorrectly. Watch an actual run before assuming the agent has learned your process.
Descriptions also need boundaries. “Helps with business” does not distinguish reporting from prospecting. “Prepare a weekly client report from approved campaign records; flag missing data; do not send it” gives the agent a much clearer match.
How are skills different from prompts, tools and memory?
A prompt requests work now; a skill packages a reusable way to perform it. A tool supplies an action the agent can take, while memory typically retains facts or prior context.
These are practical distinctions rather than universal product labels. Different agent products combine them in different ways. For choosing what to build, use this test:
- Prompt: “Prepare this week's client report.”
- Skill: “Here is our reporting procedure, template and acceptance checklist.”
- Tool: The approved connection that reads the campaign records.
- Memory: The client's agreed reporting day or preferred terminology.
Putting “read our CRM” inside a skill does not create a working CRM connection. Putting “never email a client” in the same document is not equivalent to removing email-sending access from the agent.
Keep the procedure and the permissions separate. The former tells the agent what good work means. The latter limits what the surrounding software allows it to do. That separation belongs in the design of an agentic system, before unattended work begins.
What should go into your first skill?
Start with one recurring task that has a recognizable input and a reviewable output. Write the procedure around those boundaries, rather than collecting every helpful instruction into one document.
The format specification requires a name and description in the file's opening metadata. The body can contain step-by-step instructions, examples and edge cases. Supporting directories are optional; you do not need a script merely to make the skill look complete.
For a first reporting skill, write six short sections:
When to use it. Name the task and the requests that should trigger it. Also name a nearby task it should not handle, such as changing campaign budgets.
Required inputs. Specify the client, reporting period and approved data source. If one is missing, the output should identify the gap instead of guessing.
Procedure. Describe the actual order: retrieve records, confirm the date range, calculate the figures, draft the explanation and run the checks.
Output. Provide a small example of the report structure. Label example values as examples so they cannot be mistaken for client results.
Stop conditions. Explain what happens when sources disagree or access fails. A partial report with explicit missing fields may be useful; a complete-looking report with invented figures is not.
Acceptance checks. State what must be true before the result is ready. Every figure should have a source, the reporting period should match, and recommendations should be separated from actions already taken.
Keep frequently changing facts in a maintained reference rather than copying them into several skills. This is particularly useful for marketing reporting, where a changed definition of a qualified lead can otherwise make comparisons misleading.
How can you tell whether a skill actually helps?
Test whether it improves the completed work, not whether the agent says it used the skill. Compare representative tasks with and without it, then inspect the outputs and the actions taken.
Anthropic recommends starting with evaluation: observe where an agent struggles, then add skills to address those specific gaps. That is a better starting point than building a large library before seeing a recurring failure.
For the reporting example, try a normal week, a week with missing records, and a request that includes an unauthorized budget change. These are suggested test cases, not a published benchmark or a claim about measured performance.
Ask concrete questions after each run. Did the agent select the right client? Did it flag missing data? Can you trace the figures to their sources? Did it refuse or hand off the budget change? How much correction did the reviewer need to do?
SkillSpec, an open-source project, takes this problem further with structured contracts, checks and inspectable run records alongside skills. Its documentation explicitly distinguishes auditability from a security sandbox: enforcement of tool boundaries remains the agent runtime's job.
That is a useful design lesson even if you never install the tool. A checklist inside the instructions is a request. A check against the resulting file or external record is evidence. We reviewed SkillSpec's documentation for this article; we did not benchmark its effectiveness.
What can go wrong with downloaded skills?
Downloaded skills can contain unsafe instructions, executable scripts or dependencies that reach external services. Review the whole package before giving it access to business data.
Anthropic specifically warns that malicious skills can direct agents to leak data or take unintended actions. A readable SKILL.md does not make every linked script trustworthy.
Check who maintains the package, what files it reads, which services it contacts and whether it asks for permissions unrelated to the task. If you cannot assess bundled code, start with a procedure you control and no executable additions, or have someone qualified review it.
Compatibility is another catch. The open format makes procedures portable, but it does not guarantee that every product has the same tools, dependencies or permission behavior. The specification itself calls support for its experimental allowed-tools field implementation-dependent. Test in the actual environment you intend to use.
Which task should you turn into a skill this week?
Choose the job you already know how to review and keep explaining to the agent. Capture its procedure, run a small test and improve the instructions where the output falls short.
A good first result is modest: the agent uses the correct template, stops guessing missing values and gives the reviewer a clearer deliverable. Keep client sends, spending and other consequential actions behind controls outside the skill.
If the procedure is still changing every time you perform it, settle the process before packaging it. If a simple fixed automation already performs the job reliably, a skill may add no value.
The goal is not a bigger collection of instructions. It is less repeated explanation and better work you can verify.