Claude Skills

Claude Skills are reusable instruction folders that Claude Code can load when a task calls for them. A skill can include a SKILL.md file, examples, scripts, and supporting resources. The useful unit is the workflow it teaches, not a promise of automatic quality: read its instructions and try it on a small task before relying on it.

For interface work, compare Frontend Design with Webapp Testing: one guides visual decisions, while the other checks a running application. For written deliverables, Document Coauthoring helps structure the argument, while the Word, PDF and presentation skills handle particular file formats. Pick the result you need first, then decide whether a second skill adds a useful verification step.

Choose a skill by the deliverable you need: a browser test, a document, a debugging report, or a design implementation. Read its description and example output before installing. A useful description names the task clearly enough that you can tell when the skill should run and when another workflow would fit better.

Inspect the whole folder, not only SKILL.md. Supporting scripts can introduce dependencies, and examples can assume a particular project layout. For a first trial, choose a task whose expected result you already understand. Compare the result with your project conventions and keep the instructions that actually improve that task.

Run commands beginning with claude in your terminal; enter slash commands inside Claude Code. Follow the card’s lines in order: register the marketplace, then install the named bundle. For a manually distributed skill, preserve its supporting files under the documented user or project skill directory. Restart or reload if Claude Code does not detect it immediately.

Keep one small acceptance example next to a skill you customize. Record the input, the required output and a few mistakes it should avoid. After changing the instructions or updating the containing plugin, run that same example again. This gives you a practical way to notice a regression without turning every writing or design task into a large benchmark.

For a standalone project skill, the usual layout is .claude/skills/<skill-name>/SKILL.md. A personal skill belongs under ~/.claude/skills/<skill-name>/SKILL.md. Preserve any relative folders referenced by the instructions. Copying only the main file can break examples or scripts even when Claude Code can still discover the skill name.

After setup, open the slash-command menu and check the documented invocation name. Ask for a small sample output before using the skill on a large change. If discovery fails, check the directory nesting and frontmatter, then inspect the maintainer’s installation notes. Installing the containing plugin may be required when the skill relies on other packaged components.

A skill is usually one reusable set of instructions. A plugin is a distribution bundle that can contain skills alongside commands, hooks, agents, or MCP configuration. Choose a skill when you want a focused task workflow; choose a plugin when those pieces are designed to work together. In either case, installation may introduce scripts or tool access, so check the repository first.

Installation scope and packaging answer different questions. A skill folder determines the reusable instructions and resources. A plugin determines how a set of components is distributed and updated. Either choice still needs an appropriate project or personal scope. A team-specific release checklist may belong in a repository, while a general document workflow may be useful across several unrelated projects.

The individual Anthropic skills listed here illustrate that distinction. Frontend Design and Webapp Testing are separate task definitions inside example-skills; PDF, Word, PowerPoint and spreadsheet workflows belong to document-skills. Their detail pages expose the component source and name the containing package. The directory counts these as separate skills, but they are not separate repositories and do not require repeated installation of the same package.

Choose a standalone copy when you intend to own and maintain the instructions yourself. Choose the maintained plugin when shared distribution and upstream updates matter more. If you customize an installed workflow, keep the changes somewhere you control and compare them with later upstream revisions, so an update does not silently remove the behavior your team relies on.

For example, a writing skill can hold a tone guide, a checklist, and sample documents. A publishing plugin might bundle that skill with a review agent and a command that prepares a release. The skill describes how to do a task; the plugin gives you an installation and distribution unit for the pieces that work together.

Compare the contents before choosing between similarly named projects. Check whether you need just one instruction set or the full bundle, how updates are delivered, and whether your team should share the same version. Two listings from one repository can install the same parent plugin; you do not need to install that bundle twice.