# An enterprise AI skill library: a template for categories, owners and reviews

Template · By Nolli research, The Nolli team · Published 2026-10-18 · Updated 2026-10-18 · Prices and features checked 2026-10-16

Canonical page: https://withnolli.com/blog/enterprise-ai-skill-library-template

**Short answer.** Organize the library by the job a skill does (find, check, draft, summarize, route, hand off), not by tool. Give each skill a card with an owner, a version, a test and a status: draft, trusted or retire. A second person reviews every version, and a before-and-after check on 3 to 5 real past cases decides whether a skill earns trusted.

## Key takeaways

1. Sort skills by the job they do, and put the tool, the team and the risk on the card as tags.
2. A skill earns “trusted” only after a before-and-after check on real past cases, because in SkillsBench curated skills lowered the pass rate on 13 of 87 tasks.
3. Every new version gets a second reviewer, and a skill that still fails its checks after a fix goes to retire.

Make a folder. Put one card in it for every skill your people already use. Give each card an owner, a test and a status, and name one person who keeps the index. That is a skill library, and you can have a first version of it this week in a repo or a shared doc.

The folder is the easy part. A library with no evidence in it becomes a junk drawer: forty skills, no idea which ones work, and nobody willing to delete any. This post is the template we would start from. It has a card for each skill, six categories, rules for review, versions and retirement, a cheap way to test, and ten skills to collect first. It builds on the best way to share AI skills across a company, which covers where skills live, and on our guide to what AI skills are, which covers what they are.

## Why a library without evidence turns into a junk drawer

Skills do not all help. SkillsBench is a research benchmark that runs 87 expert tasks with and without curated skills, on 18 combinations of model and agent harness. Skills raised the average pass rate. They also made 13 tasks worse.

- **33.9% to 50.5%**: Average pass rate without and with curated skills, on 87 expert tasks across 18 model and harness setups. The gain by setup ranged from 4.1 to 25.7 points. (source: SkillsBench, arXiv 2602.12670, version 4, https://arxiv.org/abs/2602.12670v4)
- **13 of 87**: Tasks where curated skills lowered the pass rate. The paper traces them to skills that prescribe one heavy method, with no stated limits and no light fallback. (source: SkillsBench, arXiv 2602.12670, version 4, https://arxiv.org/abs/2602.12670v4)
- **+21.5 vs +0.7 points**: Gain in pass rate for standard-length skills against the most exhaustive level of documentation, in the paper’s comparison of skill length. (source: SkillsBench, arXiv 2602.12670, version 4, https://arxiv.org/abs/2602.12670v4)

Those are lab tasks, not your work. Read them for the pattern. A skill that the AI wrote for itself did worse than no skill on all three setups that tested it, by 8.1 to 11.5 points. So a draft the AI wrote for you and someone posted to the channel is not a safe default.

A library that only grows has a second cost. Anthropic’s guide for enterprise admins says each skill’s name and description compete for attention, and with too many active the AI may miss the right one. It tells you to measure recall as you add skills and to stop adding when performance drops (Skills for enterprise). Clutter is not only untidy. It makes the good skills harder to find, for people and for the AI.

Here is the tension, stated plainly. Evidence takes work, and a library nobody has time to fill stays empty. A library that skips the evidence fills up and nobody trusts it. The way through is to make the evidence small and put it on the card: a before-and-after check on 3 to 5 real past cases. The section on proving it works shows how.

## The skill card: one per skill

A skill is a folder with a SKILL.md file. The open Agent Skills specification requires two fields in it. The name is lowercase letters, numbers and hyphens, up to 64 characters, and it must match the folder name. The description is up to 1,024 characters and should say what the skill does and when to use it. An optional metadata field holds anything else, and the spec’s own example puts an author and a version there.

Anthropic’s enterprise guide asks admins to keep an internal registry entry for each skill with five things: purpose, owner, version, dependencies, and evaluation status (the last evaluation date and results). The card below has those five. We added the fields we kept needing: who gets the skill, what goes in, what comes back, when not to use it, and a status.

**Template: Skill card**

Copy this into a doc, or save it as card.md next to SKILL.md. The spec allows extra files in a skill folder, and the agent loads them only when the instructions point to them. Name and description also go in the SKILL.md header.

```text
SKILL CARD

Name:               ________  (lowercase letters, numbers, hyphens; max 64; same as the folder name)
Job it does:        ________  (one sentence that starts with a verb)
Description:        ________  (what it does and when to use it; max 1,024 characters)
Do not use it when: ________  (write at least one case)
Category:           Find / Check / Draft / Summarize / Route / Hand off
Owner:              ________  (one named person who owns the work this skill covers)
Reviewer:           ________  (never the author)
Teams who get it:   ________
Inputs:             ________  (what the person gives it)
Output:             ________  (what comes back, and in what form)
Depends on:         ________  (connections, files, scripts, other skills)
Risk:               Low / Medium / High. Who checks each output? ________
How to test it:     ________  (3 to 5 past cases, one where it should stay quiet. Where do they live?)
Last test:          ___ of ___ passed with the skill, ___ of ___ without. Model and tool: ________  Date: ________  Tester: ________
Version:            ____  (major.minor)
Change note:        ________  (what changed in this version)
Last reviewed:      ________  (date)
Review again when:  the model, the tool or the process changes, or on review day
Status:             draft / trusted / retire
If retire:          reason ________  replaced by ________  remove on ________
```

- Name. Verb and object: reconcile-closed-won-deals, not revenue-helper. Nobody can tell what a helper does.
- Job it does. One sentence. If you need “and” twice, you have two skills. The SkillsBench abstract says focused skills with at most three modules beat larger or exhaustive bundles.
- Do not use it when. Write at least one case. The paper’s 13 negative tasks share a cause: one “correct” method with no stated limits. This field is the limit.
- Risk. Name the person who checks each output. “Low” with no name is a guess.
- Last test. Put the model and the tool next to the result. The paper’s own conclusion is that a skill’s effect is a property of the specific agent stack, not a constant, and Anthropic asks for tests on every model your company uses.

> **Write the description like a search result** The spec contrasts “Helps with PDFs.” with a description that names the actions and says when to use the skill. The AI decides from this text alone whether to load the skill. Write what it does, then “Use when”, then the words a person would actually type.

## Categories: sort by the job, not the tool

Do not make a folder called Claude, one called ChatGPT and one called Copilot. The Agent Skills format is an open standard that many products support (see our skills guide), so a skill can move between tools. A folder named after a tool is wrong the day you switch.

Sort by the verb in the job instead. Six cover most of what people ask an AI to do at work.

Six categories by job. The examples are the names we use later in the first-ten list. The risk column is our judgment, not a measured figure.

| Category | The job | Output you can check | Example skill | Usual risk |
| --- | --- | --- | --- | --- |
| Find | Pull the facts on one thing from places a person would search by hand. | A short brief with its sources listed. | account-research-brief | Low. Wrong facts show if sources are listed. |
| Check | Compare work with a rule or a second source and flag what differs. | A list of differences, each with a reason. | reconcile-closed-won-deals | Medium. A missed difference is invisible. |
| Draft | Write a first version in the house style. | A draft a person edits. | refund-reply-drafts | Medium. Sent unedited, it reaches a customer. |
| Summarize | Turn a long input into what a decision-maker needs. | A summary that points back to the source. | deal-desk-summary | Low to medium. A caveat can get dropped. |
| Route | Decide where something goes. | A label, a queue or a named person. | ticket-routing-rules | Medium. Misroutes cost time and usually get noticed. |
| Hand off | Give a person or an agent the steps for a recurring job. | A checklist someone else can follow. | new-hire-first-week-plan | Low. |

The category is where the skill lives. Everything else goes on the card as a tag: the team, the tool, the risk. Anthropic’s guide makes the same split. It says to group skills into role-based bundles so each person’s active set stays small, and to start with narrow, workflow-specific skills and consolidate later. Its rule for merging: only when the merged skill’s evaluations confirm equivalent performance to the ones it replaces. A bundle is a view on the library, and a skill can sit in more than one.

**Template: Folder layout and index**

No repo? Use a sheet for the index and one doc per card, and move the files into a repo or your AI tool’s library when someone who can review them is ready.

```text
skills/
  README.md                 how this library works; who the keeper is
  index.csv                 one row per skill (columns below)
  find/
    account-research-brief/
      SKILL.md              name, description, instructions
      card.md               the skill card
      tests/                3 to 5 past cases and what correct looks like
  check/
  draft/
  summarize/
  route/
  hand-off/
  retired/                  status retire: kept visible, with the reason

index.csv columns
name, category, job, owner, teams, status, version, last_reviewed, last_test_result, used_by

Rules for the index
- One row per skill. The folder name and the name in the row match.
- Search the index for the same job before you add a row.
- The keeper updates the index on the day a skill changes status.
```

## The first ten skills to collect

Collect. Do not write. Ask each team lead one question: which instruction or prompt do people on your team paste every week? Copy it as it is and mark it draft. Do not tidy the first ten before you test them. You want the baseline.

Ten examples across the six categories. They are our picks for jobs that many companies have, not ranked and not drawn from any data. Swap in the jobs your people repeat.

| Department | Skill | Category | The job | Who checks each output |
| --- | --- | --- | --- | --- |
| Finance | month-end-variance-notes | Draft | Write first-draft commentary on budget against actual. | The finance manager, before it goes anywhere |
| Finance | invoice-exception-check | Check | Flag invoices that fail the matching rule and say why. | An accounts payable clerk approves each exception |
| Revenue operations | reconcile-closed-won-deals | Check | Match closed deals to the forecast and list every conflict. | The revenue ops lead reads the conflict list |
| Sales | account-research-brief | Find | Gather the public facts on a prospect into one page. | The rep, who reads the sources |
| Sales | deal-desk-summary | Summarize | Summarize a discount request for the approver. | The deal desk analyst |
| Support | ticket-routing-rules | Route | Send each ticket to the right queue. | Spot checks by the support lead |
| Support | refund-reply-drafts | Draft | Draft the reply to a refund request. | The agent who sends it |
| People | new-hire-first-week-plan | Hand off | Build the first-week checklist for a role. | The hiring manager |
| Marketing | brand-voice-check | Check | Flag copy that breaks the style guide. | The writer |
| Legal | contract-clause-first-pass | Check | Mark clauses that differ from the standard terms. | A lawyer approves every case. The skill never decides. |

Two of the ten, the invoice and contract skills, are ones where a wrong result costs money or harms someone. Collect them anyway, and write the human check on the card on day one. The library should hold risky skills with their limits in plain sight. A risky skill that lives in someone’s private chat has no limits at all.

## The lifecycle, and who does what

**One skill, from proposal to retirement**

1. **Propose**: Anyone fills a card. Status: draft.
2. **Test on past cases**: 3 to 5 real cases, with and without the skill.
3. **Review**: A second person reads every file and the test result.
4. **Publish a version**: Numbered, to the teams on the card. Status: trusted.
5. **Watch use**: Who used it, and did the results hold. Re-test when the model, the skill or the process changes.
6. **Retire**: Reason and replacement on the card. Status: retire.

Then loop back: A failed re-test sends the skill back to draft

The order is our synthesis of Anthropic’s lifecycle in “Skills for enterprise” (plan, create and review, test, deploy, monitor, iterate or deprecate). The plain steps are the ones a shared folder does not do for you.

The three statuses. Keep the vocabulary this small so that everyone can say what a status means.

| Status | What it means | Who may use it | How it moves on |
| --- | --- | --- | --- |
| draft | Proposed or collected. Not tested, or tested and not yet reviewed. | The author and the tester. | To trusted when the check passes and a second person approves a numbered version. |
| trusted | Passed the before-and-after check, approved by someone who is not the author, published as a version. | Every team named on the card. | Back to draft on a failed re-test. To retire by the retirement rules below. |
| retire | Marked for removal. The card says why and what replaces it. | Nobody new. Current users move off before the remove-on date. | Out of every bundle, then moved to the retired folder. Never deleted. |

Five roles. A small company can give two roles to one person, except that nobody may review their own skill. Anthropic’s guide states that rule as separation of duties.

| Role | Does | Must not |
| --- | --- | --- |
| Author (anyone) | Fills the card. Writes the 3 to 5 past cases and what correct looks like. | Approve their own skill. |
| Owner (whoever owns the work the skill covers) | Keeps the skill current when the work changes. Answers for it on review day. Decides to retire it. | Leave without naming a successor. See key-person risk. |
| Reviewer (anyone but the author, ideally someone who does the job) | Reads every file. Reads the check sheet and reruns one case. Approves or rejects a version. | Review a skill they wrote or co-wrote. |
| Tester (someone who knows the work) | Marks each result pass or fail against the written “correct” lines. | Be the author, because authors grade generously. |
| Keeper (one person per library) | Keeps the index, spots duplicates, runs review day, makes the retire call when an owner is gone. | Approve skills alone. |

## Prove it works, cheaply: a before-and-after check

The check is small on purpose. You run a handful of real cases twice, once without the skill and once with it, and a person who knows the work marks the results. It is the same shape as the paper’s design, which compares matched runs with and without skills, scaled down to what one team can do.

1. **Pick 3 to 5 real past cases.** Take cases from real work that has a known good result. Include one where the skill should stay quiet. Anthropic asks for 3 to 5 representative queries per skill, covering cases where it should trigger, should not, and ambiguous edge cases. Do this today: Do this today: ask the owner for the last five times they did the job.
2. **Write what correct looks like.** Three or four lines per case, written before anything runs. Without them, the tester grades by taste. Do this today: Do this today: list the checks the owner makes before sending the work on.
3. **Run each case without the skill, then with it.** Same tool, same model, same input. If the output varies from run to run, run each case twice. SkillsBench used three trials per task and setup. Do this today: Do this today: write the exact model name next to every result.
4. **Someone who knows the work marks each result.** Pass or fail against the lines from step 2. Not the author. Do this today: Do this today: give the tester the results with the skill and the results without it mixed together, unlabeled.
5. **Write the result on the card, and decide.** Publish as trusted if the skill beats no skill on more cases than it loses and stayed quiet when it should. A tie does not get published. Every skill in the library costs attention, and a tie buys nothing for it. Do this today: Do this today: copy the two result lines onto the card.

**Template: Before-and-after check sheet**

One sheet per skill version. Keep it in the skill’s tests folder.

```text
BEFORE-AND-AFTER CHECK
Skill: ________   Version: ____   Date: ________
Tool and exact model: ________
Tester (not the author): ________

CASES (3 to 5, from real past work; at least one where the skill should stay quiet)
Case 1: ________  Source (ticket, file, date): ________
  Correct looks like:  1) ________  2) ________  3) ________
  Should the skill fire?  Yes / No
  Without the skill:  pass / fail   Notes: ________
  With the skill:     pass / fail   Notes: ________
Case 2: (same lines)
Case 3: (same lines)

RESULT
With the skill: ___ of ___ passed.    Without the skill: ___ of ___ passed.
Stayed quiet when it should: yes / no
Took over a request meant for another skill: yes / no

DECISION
Trusted if it beats no skill on more cases than it loses, and stayed quiet when it should.
A tie: do not publish.
Copy the two result lines onto the skill card.
```

Be honest about what five cases can tell you. They are a smoke test. They catch a skill that does nothing or does harm. They do not give you a pass rate to the decimal. SkillsBench used 87 tasks and three trials per setup to report averages. Your check is cheap enough to run on every skill, and that is its value. Add cases from real use as the skill collects them.

Once cards carry results, plot the library. Put how much a skill is used on one axis and how much evidence it has on the other. Start with the top-left corner. Those skills already shape work and nobody has checked them.

**Use against evidence: where to look first** (x: Evidence on the card (0 = none, 100 = checked and held up in use), 0 to 100; y: Use (0 = rarely, 100 = by many people on the job), 0 to 100; corners: top-left Test first, top-right Promote, bottom-left Retire, bottom-right Keep)

- ticket-routing-rules: x 85, y 86
- deal-desk-summary: x 26, y 74
- refund-reply-drafts: x 14, y 56
- month-end-variance-notes: x 74, y 24
- brand-voice-check: x 16, y 10

Sample data. These five points are invented to show the four corners and describe no real company. Promote: used and checked, so spread it to more teams. Test first: used and unchecked, so run the check this week. Keep: checked and rarely used, which is fine when few people do the job. Retire: unused and unchecked. Where your tool does not count use, ask the owners.

## Triage a submission: does it go in the library?

Someone will post a skill in the channel and ask you to add it. Score it on four things before it takes a slot. Reuse and evidence count most. Risk and upkeep are 5 for safe and cheap, and 1 for dangerous and expensive. The scorer below is yours to edit.

> **Sample data** The three rows are invented to show the method. They describe no real company. The tag says “Into the library” when the total reaches 3.5, which means ready for review day. The rules under the scorer can still hold a skill back.

**Score three sample submissions, then replace them with yours**

Change a dropdown and watch the order move. Rename a row or add your own.

Priority = (3 x Reuse + 3 x Evidence + 2 x Risk + 2 x Upkeep) / 10. A score of 3.5 or more: into the library.

- Reuse (How many people do this job): 1 = One person, now and then; 2 = One person, every week; 3 = A small team, every week; 4 = Several teams; 5 = Most of the company
- Evidence (How well the skill has been shown to work): 1 = None. The author says it works; 2 = The author tried it on one case; 3 = Before-and-after on 3 to 5 cases, author graded; 4 = Same, graded by someone who knows the work; 5 = Same, and it held up in real use
- Risk (Higher is safer. 5 means low risk.): 1 = Costs money or harms a customer; 2 = Costly, but a later check catches it; 3 = Hours to fix, usually noticed; 4 = Cheap to fix, usually noticed; 5 = Cheap, obvious, easy to override
- Upkeep (Higher is cheaper to maintain. 5 means little upkeep.): 1 = Scripts, several tools, rules change often; 2 = Depends on a policy or tool that changes often; 3 = One system, rules change sometimes; 4 = Plain steps, rules rarely change; 5 = Plain steps that have not changed

Sample rows:

| Workflow | Reuse | Evidence | Risk | Upkeep |
| --- | --- | --- | --- | --- |
| Sample: ticket-routing-rules | 4 | 4 | 4 | 4 |
| Sample: weekly-status-roll-up | 5 | 1 | 5 | 3 |
| Sample: contract-clause-first-pass | 2 | 2 | 1 | 2 |

The middle row is the one to study. Everybody does the job, a wrong result is cheap, and it scores 3.4 because nobody has checked it. Popularity and low risk cannot buy evidence. The bottom row fails on evidence and on risk. It can still sit in the draft area with its limits written down and a lawyer on every output.

1. Search the index first. If the job already has a skill, compare the two on the same cases, keep the one that does better and retire the other. Anthropic’s advice for overlapping skills is to consolidate them or narrow their descriptions.
2. Evidence below 3 means draft only, whatever the total.
3. Risk of 1 means the skill goes in only with a named person checking every output, written in the skill’s own instructions.
4. A total of 3.5 or more with evidence of 3 or more goes to review day.
5. Anything lower stays in the draft area. Tell the author which score held it back.

## Review, versions, retirement and review day

### Review

1. Nobody approves their own skill. Anthropic’s guide: authors should not be their own reviewers.
2. The reviewer reads every file in the folder: SKILL.md, every referenced file and every script. The guide’s checklist also asks the reviewer to confirm that scripts do what the description says, to look for instructions that tell the AI to hide actions, to search for network calls, and to check that no passwords or tokens appear in the files. Our skills guide has a short version.
3. A skill with scripts, network calls or references to MCP servers gets that full read on every version. Anthropic rates all three as high concern.
4. The reviewer reads the check sheet and reruns one case. A result they did not see is a claim.

### Versions

1. Use two numbers, major.minor. Move the major number when the job or the output changes, so downstream users notice. Move the minor number for everything else. The spec’s example keeps the version in metadata.
2. Every change makes a new version, and every version gets the check again. Anthropic says to run the full evaluation suite before promoting a new version and to treat every update as a new deployment with a full security review. For a wording-only change to a skill with no scripts, we would let the reviewer read the diff and rerun the cases. That relaxation is ours, not Anthropic’s.
3. Pin production to a version where your tool allows it. On the Claude API, Anthropic notes that leaving the version out means a new version uploaded by anyone in the workspace changes what production agents run immediately.
4. Keep the last good version. If a new one fails in production, go back to the last known good version first and investigate second. Anthropic gives the same rule.
5. Write one change note per version on the card. “1.2: added a case for part refunds” is enough.
6. Re-run the cases when the model, the skill or the process changes. A review day every quarter is the backstop for changes nobody announced.

### Retirement

1. Retire a skill when its checks still fail after a fix. Anthropic: deprecate when evaluations consistently fail or the workflow is retired.
2. Retire it when the process it encodes is gone, when a better skill does the same job, or when its owner has left and nobody takes it on review day.
3. Where your tool counts use, look at skills nobody has used since the last review. Ask the owner before you remove one, because a yearly job looks unused for months.
4. To retire: set the status, write the reason and the replacement on the card, tell the teams on the card, take it out of every bundle, then move the folder to retired/. Do not delete it. The history stops the next person from writing the same skill again.

### Review day

**Review day: go through the library in this order**

- [ ] Every row in the index has an owner who still works here and still does the job.
- [ ] Skills in the top-left of the quadrant (used often, no evidence) have been checked, or are scheduled this week.
- [ ] Every skill whose model, tool or process changed since its last test has been re-run on its cases.
- [ ] No two skills do the same job. Pairs are merged, narrowed or retired.
- [ ] Any version with scripts, network calls or MCP references had a full read by someone who is not the author.
- [ ] Skills that failed twice after fixes are marked retire, with a reason and a replacement.
- [ ] The count of skills in each team’s bundle has not made the AI pick the wrong one more often. If it has, stop adding.
- [ ] Every card you touched has today’s date in Last reviewed.
- [ ] Each owner has been asked which skill is missing from the library.

## Where Nolli fits, and where it does not

You can run this whole template by hand with a folder, a sheet and one keeper. Nolli covers the parts that take the most effort by hand. It learns how work happens from work on company devices, the email and calendar your company connects and the logs of the AI agents people use, so it can show the skills your people already use before anyone posts them. Its skills library shows who wrote each skill, who uses it, how it does on your own checks and the time it saves, re-tested every week, and it flags the ones that need work. While people work, it points them to the skill that already does the job. What it does not do: the checks are yours, so someone who knows the work decides what correct looks like. Keep version history and approval in your repo or your AI tool’s review step. Your company decides what Nolli learns from and sets the policy. We have no customer results to quote. There is no public price. Request a demo. See Nolli Equip.

## Questions people ask

**How do you organize an enterprise AI skill library?**

Sort skills by the job they do, such as find, check, draft, summarize, route and hand off, and not by tool. Give each skill a card with an owner, a version, a test and a status of draft, trusted or retire. Keep one index and one person who maintains it.

**What should be on an AI skill card?**

Name, the job it does, a description, when not to use it, category, owner, reviewer, inputs, output, dependencies, risk, how to test it, the last test result, version, last review date and status. Anthropic’s enterprise guide asks for a registry entry with purpose, owner, version, dependencies and evaluation status.

**Who should own and review AI skills?**

The owner is whoever owns the work the skill covers. The reviewer is someone else, ideally a person who does the job. Anthropic’s guide says skill authors should not be their own reviewers, and that rule holds for every skill.

**How many skills should a library hold?**

There is no right number. Anthropic says each skill’s name and description compete for attention, so measure recall as you add skills and stop when it drops. The Claude API also caps a request at 20 skills.

**How do you know a skill in the library works?**

Run 3 to 5 real past cases without the skill and with it, in the same tool and model, and have someone who knows the work mark each result. It is a smoke test, not a statistic. In SkillsBench, curated skills lowered the pass rate on 13 of 87 tasks.

**When should you retire an AI skill?**

When its checks still fail after a fix, when the process it encodes is gone, when a better skill does the same job, or when its owner has left and nobody takes it over. Mark it retire with a reason and a replacement, and keep it in a retired folder.

## Sources

- "Skills for enterprise." Claude Docs, Anthropic, accessed October 16, 2026. https://platform.claude.com/docs/en/agents-and-tools/agent-skills/enterprise
- "Specification." Agent Skills (agentskills.io), accessed October 16, 2026. https://agentskills.io/specification
- Xiangyi Li, Yimin Liu, Wenbo Chen, Bingran You and others. "SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks." arXiv (2602.12670, version 4), read October 16, 2026. https://arxiv.org/abs/2602.12670v4