# Adopting a published skill set

> Vet an invented skill set skill by skill for license, maintenance, scripts and pre-approved tools, take two of its skills, and check what they change in a session against what they add to the context.

Page: https://schubergphilis.github.io/ai-training/customizing-agents/adopting-a-skill-set/
License: CC BY-SA 4.0, https://creativecommons.org/licenses/by-sa/4.0/

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.

```sh
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 (Agent Skills (the anthropics/skills repository), GitHub).

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 (Extend Claude with skills, Claude Code documentation). 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
(Plugins overview, Claude Code documentation).
That's the first stage that
[Loading only what the skill needs](https://schubergphilis.github.io/ai-training/customizing-agents/progressive-disclosure/)
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
  (Agent Skills specification, agentskills.io). 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: List what the workbench set holds

Run this, and compare with the output below.

```sh
python3 vet.py workbench
```

Output:

```text
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
```

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 (Install and manage plugins, Claude Code documentation). An installed copy changes
only when you update it, so you can read each new release first.

#### Checkpoint: 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.0
- release-notes, which states no license
- review-diff, with license: Apache-2.0
- spreadsheet, whose LICENSE.txt reserves all rights

#### Checkpoint: 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.

## 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
(Extend Claude with skills, Claude Code documentation). 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: List the two skills you take

Run this, and compare with the output below.

```sh
python3 vet.py workbench plan-ticket review-diff
```

Output:

```text
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
```

`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 (Extend Claude with skills, Claude Code documentation).

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
  (Extend Claude with skills, Claude Code documentation).
- **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 (Extend Claude with skills, Claude Code documentation).

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 (Extend Claude with skills, Claude Code documentation).

#### Checkpoint: 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.

#### Checkpoint: What do you do with each skill?

Match each finding to what you do next.

Statements:

- The commit-message skill gave the same messages as the runs without it.
- Only you ever start the deploy skill, and its description is in every session.
- With plan-ticket, the plans in the test runs were better than without it.
- Results got worse after you added two skills on the same day.

Options:

- Delete the skill
- Set disable-model-invocation: true
- Keep it, and add the next skill
- Turn one off and run the same prompts again

#### 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
(Extend Claude with skills, Claude Code documentation). 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.

```sh
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 (How Claude remembers your project, Claude Code documentation). Replace `<project>` with the path to a
repository you work in, and `<skill-a>` and `<skill-b>` with the two
skill names.

```sh
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.

```sh
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 (Extend Claude with skills, Claude Code documentation).

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 (Agent Skills (the anthropics/skills repository), GitHub).
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
   (Plugins overview, Claude Code documentation).
4. Take one or two skills at a time. A plugin's skills come together, so
   copy single skills when the license allows it (Extend Claude with skills, Claude Code documentation).
5. Check each skill with `/context` and with the same prompts run with
   the skill on and off. Delete a skill that changed nothing.

#### 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

- Agent Skills (the anthropics/skills repository), GitHub, https://github.com/anthropics/skills
- Extend Claude with skills, Claude Code documentation, https://code.claude.com/docs/en/skills
- Plugins overview, Claude Code documentation, https://code.claude.com/docs/en/plugins
- Agent Skills specification, agentskills.io, https://agentskills.io/specification
- Install and manage plugins, Claude Code documentation, https://code.claude.com/docs/en/plugins/install
- How Claude remembers your project, Claude Code documentation, https://code.claude.com/docs/en/memory