You keep re-explaining the same job
If you use Claude for real work, you have probably noticed a pattern. Every new chat starts with the same paragraph. "Here is how we format commit messages." "Use our error-handling style." "Summarize this the way I like." It works, and then the session ends and the knowledge is gone.
Skills and Plugins are the two ways to make that knowledge stick. They are easy to confuse because both "extend" Claude, but they answer different questions. A Skill answers how do I do this job? A Plugin answers how do I ship this to a team and wire it to my tools?
A Skill teaches Claude how to do a job
A Skill is a folder with a SKILL.md file at its root. The file has a small YAML header and a body of instructions:
---
name: pr-description
description: Write PR descriptions in our team format. Use when the user opens a PR or asks to summarize a branch.
---
# PR description writer
1. Run `git diff main...HEAD` to read the changes.
2. Group them by area (API, UI, migrations).
3. Fill in `template.md`. Keep the risk section honest.
You can drop extra files next to it: a template, a reference doc, a script Claude can run. The trick worth understanding is progressive disclosure. The one-line description is always in front of Claude. The body loads only when the task matches. Larger files load only if the body points to them. So a skill can carry a lot of detail without burning context on every message.
The consequence that matters: skills are model-invoked. Claude reads the description and decides whether the skill is relevant. You are not calling a function, you are writing a note-to-self that Claude picks up when the moment fits. That makes the description the most load-bearing line in the whole file.
Reach for a Skill when you find yourself explaining the same procedure, format, or set of conventions more than twice.
A Plugin ships capabilities and connects to tools
A Skill lives in your setup. A Plugin is how you package it and hand it to other people. In Claude Code, a plugin can bundle several things at once:
- Skills (the know-how above)
-
Slash commands (e.g.
/deploy,/triage) for jobs you trigger on purpose - Subagents for delegated tasks
- Hooks that run at defined points, like before a commit
- MCP servers that connect Claude to external systems (a database, an issue tracker, an internal API)
Someone installs the plugin from a marketplace and the whole set arrives together. That is the real value: one install gives a teammate the same commands, the same conventions, and the same connections you have. Where a Skill teaches a job, a Plugin distributes a workflow and plugs Claude into the systems that workflow touches.
Reach for a Plugin when the thing you built should be repeatable across a team, or when the job needs to talk to a live tool rather than just follow instructions.
A mental model: three layers
Think of extending an assistant as three layers, from throwaway to permanent:
- Context: what you paste in the moment. Fast, precise, gone when the chat ends.
- Skills: repeatable know-how Claude loads when relevant. This is the "job."
- Plugins and MCP: packaged capabilities and live connections to your tools. This is the "workflow," and it is shareable.
Most people live entirely in layer one and wonder why they keep repeating themselves. Moving a recurring task down a layer is usually the win.
Where this is weaker (the honest part)
A few things bite in practice.
Skills are instructions, not guarantees. Because Claude decides when to load one, a vague description means it fires at the wrong time or not at all. If a step must happen every time (a lint pass, a redaction step), encode it as a script or a hook, not a paragraph of prose the model may skim.
Skills also compete for attention. Ten overlapping skills with fuzzy descriptions will misfire more than three sharp ones. Curate. Delete the ones you do not use.
Plugins and MCP add moving parts. An MCP server can be down, needs permissions, and comes from someone you are choosing to trust. Installing a plugin from a marketplace is a supply-chain decision, so read what it does before you wire it into your workflow.
And there is a boring failure mode: building a skill for a job you only do once. If you will not repeat it, a good prompt is cheaper than a folder you have to maintain.
Start small
Pick one task you have re-explained this week. Write a ten-line SKILL.md for it. Use it for a few days and fix the description until it triggers when you expect. If it turns out your team needs it too, that is when a plugin earns its place. Teach one repeatable job well before you try to ship a whole toolbox.
I write about turning AI from a chat toy into a working tool. I help build AGINE Academy, a game-based academy for learning Claude by real practice. It is an independent product and is not affiliated with Anthropic.
Top comments (1)
Great mental model. I’d add one more dimension: persistence. Before creating a Skill or a Plugin, I ask whether the knowledge belongs in the model at all. Stable, verifiable knowledge should live in code, configuration, or documentation. Skills are best for reusable reasoning patterns and workflows—not as a replacement for a source of truth. The less business-critical knowledge lives only in prompts, the easier the system is to audit, test, and maintain over time.