Agent Skill with Anthropic

An agent skill with Anthropic is a reusable package that teaches Claude how to perform a specific kind of work. In practice, a Claude skill is usually a folder with a SKILL.md file, YAML frontmatter, instructions, and optional supporting files such as scripts, references, templates, or assets. Claude uses the skill when the task matches the skill's description, then loads only the extra instructions and files it needs.

That makes Anthropic's model a useful reference point for anyone learning what an agent skill is. A prompt asks Claude to answer one request. A skill gives Claude a durable operating procedure: when to use the workflow, what source to inspect first, which tools or files matter, how to handle edge cases, and what a finished result should contain.

Anthropic's Agent Skills overview describes the product surfaces: pre-built document skills for PowerPoint, Excel, Word, and PDF work, plus custom skills that teams can create for their own domains. The deeper idea is in Anthropic's engineering post on equipping agents for the real world with Agent Skills: agents do better when procedural knowledge and organizational context live in reusable artifacts instead of being pasted into every conversation.

The strongest part of Anthropic's skill model is not the file format. It is progressive disclosure.

Claude does not need every detail of every installed skill in context all the time. Anthropic describes three rough layers: metadata that is always available, the main SKILL.md instructions that load when the skill is relevant, and additional files that Claude can open only when the task calls for them. The open Agent Skills format uses the same mental model: a skill can be a folder with SKILL.md, scripts/, references/, and assets/, but the agent should load deeper material only when needed.

That matters because real skills can get large. A PDF skill might need one short entry point plus separate instructions for form filling, OCR, splitting, merging, and extracting tables. A finance spreadsheet skill might need formatting rules, formula validation steps, and scripts for recalculation. A design skill might need principles for layout, typography, critique, and visual QA. If all of that sits in one giant prompt, the agent pays for it every time. If it is packaged as a skill, Claude can start with the small trigger description and drill down only when the work requires it.

This is the practical line between a good skill and a bloated instruction file. As in How to Write an Agent Skill That Actually Works, the job is not to tell the model everything you know. The job is to give it the shortest reliable path through the work.

Anthropic uses "skills" across several Claude surfaces, but the details matter.

Surface	What skills look like	Practical implication
Claude.ai	Users can use pre-built document skills and upload custom skills, depending on plan and settings	Useful for knowledge workers who want reusable document, brand, legal, or analysis workflows
Claude API	Developers can pass Anthropic skills such as xlsx or pptx and custom skills into a code execution container	Useful when skills need to become part of an application workflow
Claude Code	Skills are filesystem-based SKILL.md directories, discovered and invoked automatically or directly	Useful for coding workflows, repo-specific procedures, and plugin-style distribution
Agent Skills standard	A portable folder format centered on SKILL.md	Useful when you want the workflow to survive beyond one vendor surface

The Claude Code skills docs are especially useful for authors because they explain when to create a skill: when you keep pasting the same checklist, instructions, or multi-step procedure into chat. Claude Code also makes the distinction from CLAUDE.md clear. Project memory files are good for facts the agent should keep in mind. Skills are better for procedures the agent should run only when relevant.

The API surface has a different constraint. Anthropic's skills API guide says a custom skill bundle must include SKILL.md at the top level, with name and description frontmatter, and can include supporting scripts or resources. It also adds practical constraints: skill names have a strict character format, descriptions have length limits, uploads have size limits, and versions need to be managed deliberately. That is a different authoring environment from dropping a local skill into Claude Code, but the design contract is similar: name the job, describe the trigger, keep the entry point usable, and bundle the assets the workflow needs.

Anthropic's public skills repository is useful because it shows skills as real artifacts rather than abstract advice. The repository includes document skills, creative skills, development skills, and enterprise communication skills. It also points to an important tradeoff: some skills are educational examples, while the document skills that power Claude's file capabilities are source-available references with separate terms.

The PDF skill is a strong example of boundary-setting. Its trigger is not "make documents better." It covers PDF-specific work: extracting text and tables, merging, splitting, rotating, watermarking, filling forms, encrypting, decrypting, extracting images, and OCR. That scope is broad inside one file type, but still bounded by a recognizable object: the PDF.

The XLSX skill shows why scripts and validation matter. Spreadsheet work is not just prose. A reliable skill has to preserve formulas, avoid hardcoded values where formulas are expected, check for spreadsheet errors, respect existing templates, and sometimes use LibreOffice or Python tooling to recalculate and inspect the file. This is where skills become more than instructions. They combine judgment, file-specific rules, and mechanical verification.

The frontend-design skill shows a different pattern. It does not mainly teach Claude a file format. It teaches a design posture: ground the UI in the subject, make intentional typography and palette choices, avoid generic layouts, plan before building, and critique the result. That connects directly to Agent Skill for Design: design skills work best when they make taste inspectable through constraints, evidence, and review steps.

These examples have different shapes because the jobs are different. PDF and XLSX skills need tool discipline. Frontend design needs critique discipline. A support triage skill would need evidence discipline. The common pattern is not the subject matter. It is a repeatable job with a trigger, a first inspection path, supporting material, and a definition of done.

A minimal Claude skill should be smaller than most people expect. The frontmatter should make the trigger clear. The body should say how to do the job. Deeper references should be linked only when they help.

---
name: support-thread-root-cause
description: Analyze a customer support thread and produce a root-cause memo with evidence, hypotheses, missing context, and next actions.
---

# Support Thread Root Cause

Use this skill when the user provides a support thread, escalation note, or customer transcript and asks why the customer is blocked.

## Workflow

1. Read the full thread before proposing causes.
2. Extract the customer's goal, environment, timeline, and error signals.
3. Separate confirmed facts from hypotheses.
4. Check `references/product-symptom-map.md` if the symptoms mention billing, auth, imports, or integrations.
5. Return a root-cause memo with evidence, likely causes, missing context, and the smallest next diagnostic question.

## Stop rules

Stop if the thread is missing, if the task requires private account access you do not have, or if the requested action would change customer data.

This structure is useful because it gives Claude scope, sequence, escalation rules, and an output shape. It also avoids turning the skill into a second system prompt. The skill does not say "be an expert support engineer." It says exactly how to handle one recurring support job.

Anthropic skills are easiest to understand when they are compared with neighboring abstractions.

Choice	Use it when	Do not use it when
Prompt	The task is one-off and easy to inspect	The same procedure will be reused by a team
Skill	The agent needs a repeatable workflow, references, examples, or scripts	The job is just one simple instruction
Tool	The agent needs a capability such as reading files, calling an API, or editing a workbook	The missing piece is judgment about how to do the work
MCP server	The agent needs an integration layer for an external system	The agent already has access but lacks procedure
Subagent	The work needs isolated context, role separation, or parallel investigation	The work is a single reusable procedure

This is why Agent Skill vs MCP is a separate decision from "should I write a skill?" MCP can give Claude access to GitHub, Figma, Linear, or an internal service. A skill tells Claude what to do with that access: which issue fields to inspect, which design frame is authoritative, which logs prove a regression, or which publish checklist must pass.

The same distinction applies to prompts. If you only need a quick answer, a prompt is cheaper. If you are asking Claude to create a board deck every Friday, reconcile spreadsheet assumptions, or review pull requests against an internal migration guide, a skill is the stronger abstraction because it can be tested, versioned, reused, and improved.

Community skill lists and Reddit threads are noisy, but they are useful because they reveal what survives real use. A widely shared Reddit review of 30+ community Claude skills found the same pattern Anthropic's docs imply: narrow skills that solve one problem tend to work; vague "make Claude smarter" skills and complicated setup tend to disappoint. A separate Claude Code frontend thread praised Anthropic's frontend-design skill specifically because it forced more concrete visual decisions instead of generic blue-purple layouts.

Treat those community reports as anecdotal, not benchmark data. Still, they are directionally useful for skill authors. Curated lists such as awesome-claude-skills now group official document skills, frontend skills, MCP-builder skills, web-app testing skills, brand-guideline skills, and third-party workflow packs. The ecosystem is large enough that "I made a skill" is no longer interesting by itself. The useful question is whether the skill has a crisp trigger, a reliable workflow, low setup friction, and observable output quality.

That is also why publishing a skill is not the end of the work. The practical next step is testing. How to Test an Agent Skill Before You Publish It argues that a skill should be judged by repeated runs, failure modes, and feedback, not one impressive demo. Anthropic's skill authoring best practices and skill-creator guidance point in the same direction: descriptions matter because they control when Claude invokes the skill, and realistic trigger examples are better than abstract ones.

The main tradeoff is specificity versus reuse. A broad skill is easier to market but harder for Claude to apply correctly. A narrow skill is less glamorous but easier to trigger, test, and improve.

For example, "finance assistant" is too broad. "Clean a messy CSV into an audited XLSX workbook with formulas preserved and assumptions documented" is narrow enough to evaluate. "Design better UI" is too broad. "Review one settings screen for hierarchy, accessibility risk, and component consistency" is concrete enough to produce useful findings.

There is also a tradeoff between instructions and executable code. Scripts are powerful when the task has a mechanical part: recalculating formulas, unpacking a DOCX file, generating thumbnails, extracting PDF tables, or checking file integrity. Scripts are risky when they hide decisions the agent or user should inspect. A good skill uses code for repeatable mechanics and uses instructions for judgment, prioritization, and escalation.

Finally, there is a security tradeoff. Skills can contain executable code and can point Claude toward files and tools. That makes them more useful than static prompts, but also more important to review. Treat third-party skills like code dependencies: read the SKILL.md, inspect scripts before enabling them, understand what files and tools they expect, and prefer trusted sources for sensitive workflows.

Before you publish an Anthropic-style skill, check the operational contract:

• Does the description name a real trigger a user would type?
• Does the first section say when to use the skill and when not to use it?
• Does the workflow start from the highest-trust source?
• Are required inputs explicit?
• Are references short, named, and loaded only when needed?
• Are scripts reserved for mechanical steps that benefit from repeatability?
• Does the output format make the result reviewable?
• Do stop rules prevent guessing, account changes, or unsafe actions?
• Can you test the skill with realistic should-trigger and should-not-trigger examples?

If a skill depends on company context, keep that context concrete. "Follow our standards" is weak. "Read references/api-style-guide.md before drafting endpoint documentation, and return any conflicts with existing examples" is strong.

Anthropic's model is valuable because it treats skills as workflow infrastructure. A skill is not just a longer prompt, and it is not a tool by itself. It is the operating procedure that helps Claude combine instructions, files, code, and integrations into a repeatable result.

The lesson for skill authors is simple: package the smallest useful job. Give it a clear trigger. Keep SKILL.md lean. Move deep context into named references. Use scripts where mechanical reliability matters. Test whether Claude invokes the skill at the right time. Then improve it from real runs.

That is the difference between a clever Claude prompt and a durable agent skill. The prompt may solve today's request. The skill can become a reusable workflow that a team can inspect, share, measure, and keep improving.