Claude Skills and Plugins: Teaching Claude How Your Team Works

Version note: This post covers skills and plugins in Claude as of 15 November 2026; plan rules, upload steps and field limits were checked the same day in the Claude Help Center (support.claude.com) and the Claude platform documentation (platform.claude.com). This post is based on the official documentation. Anthropic rolls new features out to accounts gradually, so some of what is described here may not show up in your account yet.

Guess First

Emre wants the customer-facing release notes of Bookstore, the online bookstore used as the shared example across this site's series, always written the same way. He prepared a skill, wrote "Helps with release notes." in the description field and uploaded it from Customize > Skills. The next day he told Claude "Write a 'what's new' announcement for customers from the pull requests merged this sprint"; Claude wrote a text its own way without using the skill at all. The same day Ayşe found a skill called "excel-pro" on a forum, with a scripts folder inside, and suggested it to the team.

Two questions: why did Emre's skill not kick in? What should be checked before installing the skill Ayşe found? The answer to the first question is in how skills are loaded; the second is in the Help Center's security warning.

What a Skill Is: A Folder and a SKILL.md

A skill is a folder that teaches Claude how to do a specific job. According to the "Agent Skills" page in the Claude platform documentation (https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview), every skill has a SKILL.md file with YAML frontmatter at its root; the frontmatter has two required fields: name and description. The body of the file holds steps, examples and rules; the folder can also hold extra documents, templates and scripts.

What sets skills apart from a prompt is how they are loaded. The documentation calls this progressive disclosure and describes three levels:

The answer to the first Guess First question is in this table. Claude picks a skill by comparing your request with the only piece of information it always has, the description. "Helps with release notes." does not say when to use the skill and contains no word that would match Emre's "what's new announcement" request. However well the body is written, if the description does not match, the body is never read.

Skills need a working environment: Claude reads skill files in a sandbox and runs scripts there. According to the Help Center article "Use skills in Claude" (https://support.claude.com/en/articles/12512180), that is why the "Create and edit files" setting (formerly "Code execution and file creation") under Settings > Capabilities has to be on. In the sixth post we saw the ready-made skills that create Excel and PowerPoint files; they work through the same mechanism.

Where and on Which Plans Skills Work

According to the Help Center, skills are available on the Free, Pro, Max, Ultra, Team and Enterprise plans. Anthropic's Excel, Word, PowerPoint and PDF skills are turned on from Customize > Skills, and Claude uses them on its own for related work. To add your own skill, you package the folder as a ZIP file and upload it in Customize > Skills with "+", "+ Create skill" and "Upload a skill"; you can turn it on and off from the list. The article "How to create custom skills" (https://support.claude.com/en/articles/12512198) sets two packaging rules: the folder name has to match the skill's name, and the root of the ZIP has to be the folder itself, not its contents.

The same skill can be used on other surfaces too, but each surface has its own rule. According to the Help Center, skills in claude.ai sync one way to Claude Code (v2.1.273 and later) signed in with the same Claude account and can be seen with the /skills command; there is no sync when signing in with an API key or through a cloud provider such as Amazon Bedrock. Skills also work in the Excel, PowerPoint, Word and Outlook add-ins. The Claude API is separate: according to the platform documentation, a skill uploaded to claude.ai does not show up in the API on its own and has to be uploaded there separately. In Claude Code, skills live on the file system: personal ones under ~/.claude/skills/, project skills under .claude/skills/ in the repository. The Claude Code side is covered in the upcoming Claude Code series post "Skills and Slash Commands in Claude Code: Packaging Repeated Work", the API side in the upcoming Building Applications with the Claude API series.

Description: Where a Skill Gets Triggered

The platform documentation gives the field rules plainly: name is at most 64 characters, may contain only lowercase letters, numbers and hyphens, and cannot contain XML tags or the words "anthropic" or "claude"; description cannot be empty, is at most 1,024 characters and should say both what the skill does and when to use it. The Help Center article on uploading to claude.ai, however, gives a 200-character limit for the description. If you will use the same skill in both claude.ai and Claude Code, keeping the description under 200 characters satisfies both rules.

Let's put Emre's description next to one that works:

description: Helps with release notes.

description: Writes customer-facing Bookstore release notes from commits or
  merged pull requests. Use when asked for release notes, a changelog or a
  what's-new post.

The second one says three things: what is produced (customer-facing release notes), what the input is (a list of commits or pull requests) and which requests it is for (release notes, changelog, what's-new). Since users ask for the same job in different words, putting synonyms into the description raises the chance that the skill triggers in real use. The Help Center's testing advice points the same way: after uploading, try the skill with several different prompts, check in Claude's thinking whether the skill was loaded, and fix the description if Claude does not use the skill where you expect it to.

Bookstore: The Release Notes Skill

The skill's folder structure is kept small; in line with the Help Center's advice, we start without scripts, with Markdown only:

bookstore-release-notes/
    SKILL.md
    template.md
    banned-words.md
    examples/2026-10.md

The SKILL.md file:

---
name: bookstore-release-notes
description: Writes customer-facing Bookstore release notes from commits or
  merged pull requests. Use when asked for release notes, a changelog or a
  what's-new post.
---

# Bookstore release notes

Follow these steps in order.

1. Read the commit or pull request list the user gives you. If there is
   no list, ask for one; never invent changes.
2. Drop changes customers cannot notice: refactoring, tests, CI,
   dependency updates without a visible effect.
3. Sort the rest into the sections in template.md.
4. Rewrite each item for a customer: what they can do now, in one sentence.
   No ticket IDs, class names or endpoint paths.
5. Check the draft against banned-words.md and remove every match.
6. Write in the language the user asks for; default to Turkish.
7. End with a short "Not included" list that names the dropped items,
   so the team can check what was left out.

See examples/2026-10.md for an approved release note.

The template and the banned-word list sit in separate files:

# template.md
## New
## Improved
## Fixed
(Translate the section titles into the output language.)

# banned-words.md
Never use these in customer-facing text:
- refactor, migration, endpoint, null, exception, hotfix
- internal ticket IDs such as BOOK-1234
- dates or promises about future releases

This structure has two design decisions. The first is the "Not included" list: having Claude list separately the changes it considers invisible to customers makes it easy for Selin to ask "why is this fix not in the notes?"; a skipped returns fix can be important information for Gül's support team. The second is keeping the rules in separate files: as the banned-word list grows, the SKILL.md body does not change, and the file is read only in step 5.

After uploading the skill, four prompts are enough to measure triggering. The skill should load for the first two and not for the last two:

The fourth row tests the description's boundary: in a changelog written for the internal team, class names and endpoints are fine. If Claude applies the customer skill to this request too, you need to add a sentence such as "not for internal changelogs" to the description. If you put the same folder in the repository under .claude/skills/bookstore-release-notes/, Ayşe and Emre use the same rule in Claude Code as well; the skill has a single source, and changes are reviewed through pull requests.

Sharing Skills in a Team

On Team and Enterprise, skills can be shared from person to person and with the organization. According to the Help Center, skills are on by default at the organization level on Team; on Enterprise, owners need to check that the "Code execution and file creation" and "Skills" settings are on in the Policy tab under Organization settings > Plugins & skills. Owners can provision skills to all users; provisioned skills show up with a team indicator. It is also possible to turn off users creating their own skills; on Enterprise, if custom roles are used, a user also needs the "Create skills" capability.

A shared skill is view-only for the recipient, and updates reach the recipient automatically. To open a skill to the whole organization there is a "Publish to org" step; if review is required, a reviewer checks the skill first and can make it available, installed by default or required. On Bookstore, Selin could own the release notes skill: she sets the rules, Emre and Ayşe suggest changes, and the published version reaches everyone at the same time.

Plugins: Skills, Connectors and More

A plugin is a package. According to the Help Center article "Use plugins in Claude" (https://support.claude.com/en/articles/13837440), a plugin bundles skills, connectors and sub-agents into one package; it can also include hooks and local MCP servers. A plugin's skills and commands appear as slash commands and are listed when you type "/". Plugins are on all paid plans (Pro, Max, Ultra, Team, Enterprise) and are added from Discover in the Plugins tab of the Customize menu, with "Add".

Not every part of a plugin works everywhere. Skills and commands work in chat on the web, in Desktop and in Cowork; hooks and sub-agents work only in Cowork and Claude Code and appear grayed out in chat. You can upload a plugin file you made yourself or build one step by step with the "Plugin Create" plugin. The Knowledge Work marketplace is added by default; adding a repository on GitHub, GitLab or Bitbucket as a marketplace is also possible. According to the release notes, the plugin marketplace came to Cowork on 24 February 2026, and since 25 September 2026 developers can submit their plugins to the Claude directory through a new portal.

On Team and Enterprise, owners distribute plugins through marketplaces or approve plugins users publish to the organization library. Plugins made required cannot be turned off or removed, even in Claude Code. Owners can limit which marketplaces may be used and can turn off local MCP servers entirely. A sensible plugin for Bookstore would package the release notes skill together with the Bookstore connector from the eighth post: the skill says how to write, the connector says which data to read.

Security: Installing a Skill Is Installing Software

The answer to the second Guess First question is written plainly in the Help Center: install skills only from sources you trust. Skills can install third-party packages and software or have Claude install them; according to the article, the main risks are prompt injection and data exfiltration through malicious package code or injected data. Before turning on a skill from a less trusted source, you need to look at every file in it, especially dependencies, scripts and instructions to connect to external networks.

The platform documentation makes the same warning more strongly: treat a skill like installing software; skills that fetch data from external URLs are especially risky, because fetched content can carry instructions and a dependency that is trustworthy today can change tomorrow. The job for the "excel-pro" skill Ayşe found is clear: read SKILL.md from start to finish, understand what every file in the scripts folder does, and look for any line that sends requests out or touches unexpected files; if there is something you do not understand, do not install it.

Enterprise has an extra layer. According to the release notes, skill and plugin security scanning, in beta since 6 August 2026, scans uploaded or edited third-party skills and plugins for malicious content before they run. According to the plugin article, plugins found to be malicious are blocked and risky-looking ones are shown with a caution banner. The platform documentation also notes that the scanning does not cover skills uploaded through the Skills API or the Claude Console. Scanning is a good safety net, but it does not do the reading for you.

In Production

Manage a skill like code. A skill that lives in a repository, changes through pull requests and has a known owner is more reliable than a copy someone uploaded to their own account. After every significant change, run the prompts in the triggering table again.

One skill, one job. That is the Help Center's advice too: each skill should focus on a single workflow. A skill for "everything on Bookstore" blurs the description and starts triggering in the wrong places.

Do not put secrets in it. API keys and passwords are not written into skill files; if access to an external service is needed, that belongs in the connectors from the eighth post. Do not mix up the layers either: rules that hold in every conversation go into Instructions for Claude, a job's context into a project, and how a job is done into a skill.

Common Pitfalls

Writing a vague description. The skill never triggers. Write what it does and which requests it is for, in the words users actually use.

Packaging the ZIP wrong. Package the folder itself, not its contents; the folder name should match the skill name.

Installing a skill from an untrusted source. A skill can run scripts and install packages. Do not install it without reading every file.

Using a skill instead of Instructions. A rule that holds in every conversation (for example "answer in Turkish") goes into Instructions for Claude, not a skill; a skill loads only when the related job comes up.

Assuming a skill exists on every surface automatically. Sync from claude.ai to Claude Code is one way and depends on signing in with the same account; for the API you have to upload it separately.

A Small Experiment

★☆☆ Open Customize > Skills and check whether Anthropic's ready-made skills are on. Ask for an Excel file and see in Claude's thinking that the xlsx skill was loaded.

★★☆ Prepare a skill like the one in this post for a job your team does often: SKILL.md, a template and a rules file. Keep the description under 200 characters and test it with a four-prompt triggering table.

★★★ Review a skill with scripts that you found on the internet, without installing it. For every file, write in a table what it does, whether it reaches the external network and which packages it installs; at the end, give a "would install" or "would not install" decision with your reasons.

Skills teach Claude how to do a job. In the tenth post we move on to Claude doing that job over a long time, in many steps and sometimes in your browser: Cowork tasks, Claude in Chrome and safe permission settings.