Adopting a published skill set

A colleague recommends workbench, a set of eight skills for everyday development work, from ticket plans to commit messages. The set is published as one plugin, and your team wants two of its skills. In this lesson we vet the set the way you would vet a library and take the two skills. Then we check what they change in a session against what they add to the context.

The set is invented for the course. It is in the course repository at site/examples/customizing-agents/adopting-a-skill-set/workbench/, next to a short Python script, vet.py, that lists what each skill in a set holds. The script only reads files, and nothing in this lesson installs the set or runs its scripts. Run the commands from that directory, and replace <course-repo> with the path to your copy of the course repository.

cd <course-repo>/site/examples/customizing-agents/adopting-a-skill-set

What you take on with a skill set

Published skill sets are collections of skills that a vendor or a developer maintains for other people to install, often as a plugin. Model vendors, tool makers and individual developers all publish them. A set like this is a dependency, and its skills act in your sessions. They change whenever the author releases a new version.

One set can also hold skills under different licenses. Anthropic’s own public set is an example: many of its skills are under the Apache License 2.0, and its document skills are source-available, so you can read them, but they aren’t open source [1].

A skill acts in more ways than its text suggests. Its instructions tell Claude what to do, and the steps can tell Claude to run the scripts that come with the skill. A skill’s front matter can also have an allowed-tools field. While the skill runs, Claude may use the tools it lists without asking you first. That means the author of the skill decides part of your permissions. The field takes effect even in a folder that you never marked as trusted, so read it in every skill that you didn’t write [2]. When the set is a plugin, it can bring hooks and servers as well, and the previous lesson read those.

Even while nothing in it runs, a skill set has a cost. An enabled plugin adds a short entry to every turn of every session: the name and the description of each skill that Claude may start by itself. Claude reads the rest of a skill’s SKILL.md only when the skill is used [3]. That’s the first stage that Loading only what the skill needs measured for one skill, and a set has one such entry per skill.

Vet the set as you would a library

Before you install a set, look for these answers.

• License. Under which license is each skill you plan to use? The open skill format has an optional license field in the front matter, for a license name or the name of a license file next to the skill [4]. A skill with neither gives you no permission to copy it.
• Maintenance. Who maintains the set, when did it last change, and how are its changes released? A changelog, versions and an issue tracker answer most of this. Note the version or the commit that you read.
• Contents. What does each skill do? Read every skill, every script and every allowed-tools line before you install. The previous lesson did the same for a plugin’s hooks and servers.
• Alternatives. What else would do the job? A set of eight skills is eight descriptions in your context and eight things to keep up to date. When you need two of them, copying those two or writing your own can be cheaper.

vet.py answers the license question and part of the contents question for every skill at once. Each skill gets one line. It shows the license and the number of scripts, then who may invoke the skill and an estimate of the tokens its name and description add to every session. It counts the same text with the same rule as inventory.py in the previous lesson. A skill that only you may invoke counts as 0 tokens, because its description stays out of the context. When a skill has an allowed-tools line, the script prints it at the end of that skill’s line.

Example · run it

List what the workbench set holds

Run this, and compare with the output below.

python3 vet.py workbench

Output

set license: none
marketplace workbench-market:
  plugin workbench 3.2.0: 8 skills
skills: 8
  commit-message: Apache-2.0; no scripts; Claude or you; always loaded 30
  deploy: Apache-2.0; no scripts; you only; always loaded 0
  plan-ticket: Apache-2.0; no scripts; Claude or you; always loaded 32
  release-notes: none stated; no scripts; Claude or you; always loaded 32
  review-diff: Apache-2.0; no scripts; Claude or you; always loaded 29
  setup-env: Apache-2.0; 1 script; Claude or you; always loaded 42; pre-approves Bash(python3 *)
  spreadsheet: Copyright 2026 The workbench authors. All rights reserved.; 2 scripts; Claude or you; always loaded 39
  write-tests: Apache-2.0; 1 script; Claude or you; always loaded 26
always loaded, whole set: 230

Output verified in CI from site/examples/customizing-agents/adopting-a-skill-set/whole_set.py.

The set has no license file at the top, so each skill has its own terms. Every skill except two is under Apache-2.0. release-notes states no license at all, so you have no permission to copy it. spreadsheet has a license file that reserves all rights. Open workbench/skills/spreadsheet/LICENSE.txt: it allows use through the plugin and nothing else.

Read the setup-env and deploy lines more closely. setup-env pre-approves Bash(python3 *), so while it runs, Claude may run any python3 command without asking you. Open workbench/skills/setup-env/scripts/bootstrap.py. It writes a settings file to ~/.workbench/ in your home directory, outside every project. That file turns on telemetry. deploy is the opposite case. Only you can start it, by typing its name. Its description stays out of the context.

For maintenance, open workbench/CHANGELOG.md. It lists three releases in three months, each with a date and a line per change, and version 3.2.0 is the one you read. The set’s marketplace isn’t one of Anthropic’s official ones, and auto-update is off by default for such a marketplace [5]. An installed copy changes only when you update it, so you can read each new release first.

Checkpoint · multi-choice

Which skills may you copy?

Your team wants to copy skills from the set into its own repository. Which two may it copy?

Select exactly 2.

plan-ticket, with license: Apache-2.0release-notes, which states no licensereview-diff, with license: Apache-2.0spreadsheet, whose LICENSE.txt reserves all rights

CheckHintSkip

Checkpoint · choice

Read setup-env before you use it

Which statement about setup-env is right?

Its Apache license shows that the skill is safe to run in your projects.A skill holds only text, so it cannot change files outside the project.While it runs, Claude can run any python3 command without asking, so read the script first.The allowed-tools line takes effect only after you approve it once.

CheckHintSkip

Take two skills at a time

Adopt a set one or two skills at a time, and use them on real work for a while before you add more. When only one thing changed, a better or a worse result points to the skill that caused it.

A plugin doesn’t let you pick from its skills. The skillOverrides setting, which hides one personal or project skill or keeps it out of the context, doesn’t apply to skills that come from a plugin. You manage those with /plugin, by turning the whole plugin on or off [2]. When a set publishes each skill as its own plugin, install only the plugins you need. When it publishes one plugin, like workbench, copy the two skills whose license allows it into the project’s .claude/skills/ folder, and write down the version you copied. From then on, you take updates by hand, after you read the changelog.

For workbench, take plan-ticket and review-diff. Both are under Apache-2.0, have no scripts and pre-approve no tools. Give vet.py their names after the set’s directory, and it lists only those two, with their cost next to the cost of the whole set.

Example · run it

List the two skills you take

Run this, and compare with the output below.

python3 vet.py workbench plan-ticket review-diff

Output

set license: none
marketplace workbench-market:
  plugin workbench 3.2.0: 8 skills
skills: 8
  plan-ticket: Apache-2.0; no scripts; Claude or you; always loaded 32
  review-diff: Apache-2.0; no scripts; Claude or you; always loaded 29
always loaded, the 2 you named: 61
always loaded, whole set: 230

Output verified in CI from site/examples/customizing-agents/adopting-a-skill-set/two_skills.py.

plan-ticket and review-diff add an estimated 61 tokens to every turn, and the whole set would add 230. The estimate is small next to a context window, but it is paid on every turn, and it grows with each set you add. When there are many skills, Claude Code also shortens or drops descriptions to fit its listing into a fixed share of the context, and a skill whose description is dropped is harder for Claude to match to a request [2].

In a real session, check two things after you add the skills.

• What they cost. Run /context before and after you add them. Its Skills row shows the size of the skill listing that the model receives [2].
• What they change. Collect two or three real prompts, and run each one in a fresh session with the skill on and again with it set to "off" in skillOverrides. When Claude starts a skill, you know that its description matched. Only the comparison shows whether the result got better [2].

Then act on what you found. A skill that didn’t change the results still costs context and still needs updates, so delete its folder. When you start a skill yourself now and then and never need Claude to start it, give it disable-model-invocation: true in its front matter, and its description leaves the context. After a few weeks, /skill-doctor lists the context that each skill takes and how often it was used, and it marks the skills that nobody ever invoked [2].

Checkpoint · scenario

Two skills from a plugin of eight

How does the team start?

Install the plugin, then set the six other skills to "off" in skillOverrides.Copy plan-ticket and review-diff into the project's skills folder, and note the version.Install the plugin, and tell Claude in the project instructions to use only the two skills.

DecideHintSkip

Checkpoint · match

What do you do with each skill?

Match each finding to what you do next.

The commit-message skill gave the same messages as the runs without it.Choose…Delete the skillSet disable-model-invocation: trueKeep it, and add the next skillTurn one off and run the same prompts again

Only you ever start the deploy skill, and its description is in every session.Choose…Delete the skillSet disable-model-invocation: trueKeep it, and add the next skillTurn one off and run the same prompts again

With plan-ticket, the plans in the test runs were better than without it.Choose…Delete the skillSet disable-model-invocation: trueKeep it, and add the next skillTurn one off and run the same prompts again

Results got worse after you added two skills on the same day.Choose…Delete the skillSet disable-model-invocation: trueKeep it, and add the next skillTurn one off and run the same prompts again

CheckHintSkip

Pitfall: Eight skills for two

A developer installs the whole workbench plugin at user scope to get plan-ticket. A month later, they find a file ~/.workbench/settings.json in their home directory, with telemetry turned on, and they don’t remember approving it. The setup-env skill matched the request “set up this project”, and its allowed-tools line let Claude run bootstrap.py without asking. The commit messages also look different in every project, and it is not clear which skill did that. A set brings every skill in it into every session where it is enabled. Read the allowed-tools line and the scripts of each skill, and take only the skills you need, one or two at a time.

Exercise

Pick one public skill set yourself, for example one from a model vendor, a tool maker or a developer whose work you follow. Vet it, take two of its skills into a scratch copy of a project, and compare what they change with what they add to the context. Know what the skills can change before you start. Their steps can edit files, run their scripts and run commands, and an allowed-tools line lets Claude use the tools it names without asking, even in a folder you never marked as trusted [2]. The exercise uses a fresh clone with no way to push, and in the test sessions you ask for a plan or a report rather than a commit or a deploy. That protects your project and nothing else. A skill’s scripts run with your user rights, so they can change files in your home directory as well. The skills you pick have to be safe outside the clone too.

These commands fetch the set into ~/set-read and show its recent history. The first line deletes ~/set-read, so the commands also work on a second attempt. Replace <set-url> with the set’s repository.

rm -rf ~/set-read
git clone -q <set-url> ~/set-read
git -C ~/set-read log -5 --format='%h %cs %s'
python3 <course-repo>/site/examples/customizing-agents/adopting-a-skill-set/vet.py ~/set-read

vet.py reads skills in skills/<name>/SKILL.md, and it stops with a message when the set has none there. If the set keeps them somewhere else, read the folders by hand. Write down the commit at the top of the log. Pick two skills whose license allows copying, run vet.py again with their names, and read every file in their folders, the scripts included. Both skills must have no allowed-tools line, and each of their scripts must change only files inside the project, as with plan-ticket and review-diff in workbench. If no two skills in the set pass, pick another set, or stop here and write the vetting part of the note below. Then make the scratch copy and start a session in it with auto memory off, so that one test run can’t leave notes for the next [6]. Replace <project> with the path to a repository you work in, and <skill-a> and <skill-b> with the two skill names.

rm -rf ~/skill-trial
git clone -q <project> ~/skill-trial
cd ~/skill-trial
git remote remove origin
CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 claude

Run /context and note the Skills row, then quit. Copy the two skills in, start a new session the same way, and run /context again. The cp line expects the skills in skills/<name>/, so change the paths if the set keeps them elsewhere.

cd ~/skill-trial
mkdir -p .claude/skills
cp -R ~/set-read/skills/<skill-a> ~/set-read/skills/<skill-b> .claude/skills/
CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 claude

For each skill, run one real prompt that it is meant for in a fresh session, and again in a fresh session with that skill set to "off". The /skills menu sets it: select the skill, press Space until it shows off, and press Esc to save [2].

A good result is a short note. It names the set, the commit you read, the license of each skill you took, what each of their scripts and allowed-tools lines can change, the Skills row before and after, and for each prompt whether the skill changed the result. It ends with what you would do with each of the two skills: keep it, make it user-invoked or delete it. Would you have found the same answers by installing the whole set and trying it?

Stretch: After a week of real work with the two skills, run /skill-doctor, remove any skill that didn't change a result, and only then take a third one from the set.

Recap

1. Published skill sets are dependencies that act in your sessions and change with each release. One set can also mix licenses from one skill to the next [1].
2. Vet a set before you install it: the license of each skill, who maintains it and how it changes, every skill, script and allowed-tools line, and the option of writing the few skills you need.
3. Each skill that Claude may start by itself puts its name and description into every session, whether it runs or not [3].
4. Take one or two skills at a time. A plugin’s skills come together, so copy single skills when the license allows it [2].
5. Check each skill with /context and with the same prompts run with the skill on and off. Delete a skill that changed nothing.

You can now

• Vets a published skill set before installing it, as they would a dependency
• Adopts a few skills at a time and checks each one's effect and context cost

Mark lesson finishedI know this, skip it

Habit

The next time you find a skill set you like, take two of its skills and note the commit you read. Add a third only after one of the first two changed a result.

References

1. Anthropic. Agent Skills (the anthropics/skills repository). GitHub. Reference. anthropics skills
2. Anthropic. Extend Claude with skills. Claude Code documentation. Reference. Claude Code skills
3. Anthropic. Plugins overview. Claude Code documentation. Reference. Claude Code plugins
4. Anthropic. Agent Skills specification. agentskills.io. Reference. Agent Skills spec
5. Anthropic. Install and manage plugins. Claude Code documentation. Reference. Claude Code plugin install
6. Anthropic. How Claude remembers your project. Claude Code documentation. Reference. Claude Code memory