//
Search across all documentation pages
Some tasks come up again and again, and explaining them from scratch every single time is wasted effort.
Agent Skills exist to solve exactly that: a way to package instructions for a specific recurring task once, and let Claude reach for that package automatically whenever it fits.
This page introduces what a Skill actually is, how Claude finds and uses one, and where Skills fit alongside Research mode and connected tools.
Think of a Skill the way you'd think of a recipe card in a kitchen.
The recipe doesn't cook the meal by itself, but it captures exactly how to do it - the steps, the order, the details that are easy to forget - so anyone who picks it up can produce a consistent result.
An Agent Skill is that same idea, applied to a task Claude can perform: a folder containing instructions for how to do the task, plus a short description of what kind of request the Skill is for.
That description is what makes a Skill different from a saved prompt sitting in a file somewhere.
Claude actively checks incoming requests against the descriptions of available Skills, so a Skill can get used without anyone explicitly asking for it by name.
A Skill can be as narrow as "format this specific kind of weekly report" or as broad as "clean up messy tabular data before analysis" - the scope is up to whoever builds it.
The mechanic that matters most is discovery: Claude compares the shape of your request against the descriptions of Skills it has access to, and loads the instructions of any Skill that matches closely enough.
This happens automatically, without you needing to know a Skill exists or say its name.
You ask: "Clean up this messy spreadsheet export and
standardize the date formats."
Claude checks: Does an available Skill's description match
this kind of task?
If yes: Claude loads that Skill's instructions and
follows them for this request.
If no: Claude handles the request using its own
general reasoning instead.Once a Skill is loaded, its instructions guide how Claude approaches the task for that request - the same way a recipe guides a cook, without removing the cook's judgment on how to handle an unexpected ingredient.
The second mechanic is portability.
A Skill built once is meant to work the same way across Claude.ai, Claude Code, and Cowork, rather than being tied to just one surface.
That matters because a team might define a Skill for, say, a specific document review process, and then have that same Skill apply whether someone invokes it from a chat, from a coding environment, or from a collaborative workspace.
The third mechanic is explicit invocation as a fallback to automatic discovery.
If you know a Skill's name, you can ask for it directly, which is useful when several Skills could plausibly apply to the same request, or when you're testing a newly written Skill before trusting it to trigger on its own.
The single biggest factor in whether a Skill actually gets used is the quality of its description.
A description that's too vague ("helps with reports") competes poorly against other Skills and general reasoning for matching requests.
A description that's specific about what kind of task it covers and what it produces gives Claude a much clearer signal for when to load it.
This is the same reason a badly labeled recipe card gets skipped in a recipe box even if the recipe itself is good - discoverability is a property of the description, not just the instructions behind it.
Skills also compose with the rest of the Claude product surface rather than replacing it.
A Skill can shape how a Research mode report gets formatted for a recurring research task, or standardize how Claude should handle results coming back from a connected tool - the Skill doesn't do the researching or connecting itself, it shapes the process around it.
| Approach | Strength | Weakness | Best Fit |
|---|---|---|---|
| Re-explaining the task each time | No setup required | Inconsistent results, wasted repetition | One-off tasks that won't recur |
| An Agent Skill | Consistent, automatically discoverable, portable across surfaces | Only as good as its description; needs upkeep as the task evolves | Tasks a team repeats in a similar way |
| A saved prompt/template outside Claude | Simple to write | Claude can't discover or load it automatically; has to be pasted in manually each time | Very simple, rarely-reused snippets |
As a team accumulates more Skills, keeping descriptions distinct from each other becomes its own discipline - two Skills with overlapping descriptions can compete for the same request in ways that are hard to predict, which is one reason Skill design gets its own dedicated section on this site.
A folder of reusable instructions for a specific recurring task, paired with a description that tells Claude when the Skill applies - Claude can discover and load it automatically for a matching request.
No.
How closely your request matches each Skill's description - a specific, well-written description gives Claude a clearer signal than a vague one, which is why description quality matters as much as the instructions themselves.
Yes - Skills are portable across Claude.ai, Claude Code, and Cowork by design, so a Skill built once can apply wherever the matching task comes up.
Anything your team does more than a handful of times in a similar way - a recurring report format, a review checklist, a data-cleanup routine - rather than a true one-off request.
Yes - a Skill can standardize how a recurring research task should be framed or how its report should be formatted, while Research mode still does the actual planning, searching, and citing.
Claude simply handles the request using its own general reasoning, the same as it would if Skills didn't exist for that kind of task.
Yes, if their descriptions overlap - this is a real design consideration, and it's why keeping Skill descriptions specific and distinct from each other matters as a team's Skill library grows.
No.
A Skill packages instructions for how to do a task; a connector gives Claude access to an outside data source like Slack or Google Drive. A Skill might guide how Claude uses results from a connector, but the two are separate concepts.
Anyone with the right access can build one - it's a matter of writing clear instructions and a description, which is covered in more depth in this site's dedicated section on designing and packaging Skills.
Yes - one practical way is to ask for the Skill by name directly on a task you know it should cover, and compare that to what happens when you phrase the same task without naming it.
Because discovery is entirely based on matching your request against Skill descriptions - a Skill with excellent instructions but a vague description may simply never get loaded for the tasks it was built for.
Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5. Model names, pricing, and product features move quickly - verify current specifics at platform.claude.com/docs before relying on them.