Eight months into running GTM on Claude, I did an inventory. Forty-one prompts in a Slack channel called #ai-prompts, most of them screenshots. Nine Projects named things like 'Marketing', 'Marketing 2', and 'Sales stuff'. Three different versions of the pre-call brief, each slightly better than the last and each still in daily use by somebody. Four prompts that referenced a value proposition we had retired in the spring. Nobody could say which of the forty-one worked, and two reps were quietly maintaining private Notion pages of the ones they trusted.
That inventory had a name by the end of the afternoon: prompt debt. Every clever one-off the team could not find, reproduce, or fix. It is the same shape as technical debt and it accrues faster, because writing a prompt takes a minute and nothing forces you to file it. This is how I paid it down and what the library looks like now: two containers, one owner per play, a naming rule, a changelog, and a retirement habit. It is less exciting than the prompts. It is why the prompts still work.
Prompt debt, and how a team gets there
Prompt debt starts with generosity. Someone writes a good prompt, shares it, and a colleague improves it and shares that. Two months later there are five variants, each a little better for the person who made it, none of them canonical. Then the positioning changes and three of the five keep shipping the old story, because a prompt is a text file with no idea it is out of date. A Slack channel accelerates all of this: it is where prompts go to be seen once and never found again.
The cost shows up in three places, and none of them is on a dashboard. Reps spend time re-deriving prompts a colleague already perfected. Output quality varies by who wrote the version you happened to copy, so the same play produces a great brief for one AE and a generic one for another. And the failures are silent: the follow-up that quoted a retired feature went to a real prospect, and I only found out because the AE forwarded the reply. The Project did not fail. My maintenance did.
The fix is a library in the boring sense: a place things live, a name for each thing, a person who owns it, and a way to know which version is current. GTM teams already run this for battlecards and sequences. Prompts and skills deserve the same treatment, and Claude gives you two containers that make it natural if you use them for what they are for.
TipDo the inventory before you design anything. Count the prompts, the Projects, and the variants. The number is the argument for the library, and it is always bigger than you think.
Two containers: Projects for context, Skills for plays
The mistake in my nine Projects was that they held both the shared context and the plays, so every play was duplicated per Project and every Project drifted. Claude actually gives you two different containers, and the library gets simple the moment you use each for one thing. A Project holds the context a role shares: the ICP, the positioning, the tone, the objection handling, the current pricing. Everyone on the team who does that kind of work lives inside it, and every chat inherits the context without anyone re-pasting it.
A Skill holds a play: the repeatable procedure with its inputs, steps, output format, and rules, written once in a file and invoked by name. The pre-call brief is a skill. The post-call follow-up is a skill. The Monday pipeline digest is a skill a routine runs. Skills are available across Pro, Max, Team, and Enterprise, and on business plans admins can provision them centrally so they show up for everyone, or members can share theirs org-wide from Organization settings. In Claude Code the same skill is a folder in the repo, which means it is in version control by default.
The rule that falls out: context goes in a Project, procedure goes in a Skill, and a prompt pasted into both is a bug. Our 'Sales' Project now holds one page of ICP and positioning and zero plays. The plays are eleven skills with names, owners, and version numbers. When positioning changes, I edit one Project page and every play picks it up. When a play changes, I edit one skill file and every rep gets the new version on the next run.
- A one-off ask, just this once Prompt
- The same task, done the same way every time Skill
- Persistent context for a whole body of work Project
- Project: who we sell to, what we say, how we sound, what is true right now. Changes when the business changes. Owned by the role lead.
- Skill: how to do a specific job, step by step, with the output shape. Changes when the play improves. Owned by whoever runs the play most.
- Prompt (the loose kind): a one-off question. Fine to keep in a personal note. Never the canonical home of anything the team repeats.
Organize by play, never by tool or person
Libraries die of bad taxonomy. Organize by tool ('Claude prompts', 'ChatGPT prompts') and the folder outlives the tool choice. Organize by person ('Priya's research prompt') and the folder outlives Priya's tenure on the team, which is how a great prompt becomes an orphan. Organize by play, the job to be done, and the structure survives every change of tool and staff, because the jobs are the stable thing in a GTM org. Reps will always need to prep for a call. They will not always use the same tool to do it.
A play has a name a rep would use out loud: pre-call brief, post-call note, inbound reply, competitor teardown, weekly digest. Under the play sits one canonical skill, its owner, its current version, and the role or roles it serves. Our library is a single page, grouped by funnel stage, that lists each play once. It is short enough to read in a minute, which is the test: if a new rep cannot find the right play in sixty seconds, the taxonomy is wrong.
The skills and prompts on this site are organized the same way, by play and stage, which is not a coincidence. When a team adopts one of them, it lands in the library under the play it serves, gets an owner, and starts its version history at the number on the page.
TipName the skill file after the play, in kebab-case, and put the version in the file header, not the filename. `pre-call-brief` with `version: 3` inside beats `pre-call-brief-v3-final-FINAL`.
One owner per play, in the file
Every play in the library has exactly one owner, and the owner's name is in the skill file, next to the version. A person with a name, rather than a team label like 'RevOps'. The owner is whoever runs the play most, which is usually not me, and that is the point: the person who feels the play's rough edges every day is the person who should be allowed to fix them. My job is to own the library, the conventions, and the review, and to own the few plays that are genuinely systems work, like the pipeline digest.
An owner does four things. They accept or decline proposed changes to the play. They keep the changelog honest. They watch the usage numbers for their play and ask why when it drops. And they retire it when it stops earning its slot. A play whose owner has left the team is reassigned within the week or it is retired; a play with no owner is already retired, the team just has not noticed. That sentence is on the library page, and it has ended three arguments.
The failure I am guarding against is the one from my inventory: three versions of the pre-call brief, all in use, none canonical, because nobody had the standing to say 'this one'. An owner has the standing. The other two versions became a changelog entry and a lesson.
Version it like software, because it is
A skill file is code that happens to be written in English, and it deserves the same discipline: a version number, a changelog, and a review before it ships to everyone. In Claude Code this is nearly free, because the skill lives in the repo and every change is a commit with a message. In the Claude app, the skill is a file you upload, so the discipline has to be a habit: bump the version in the header, add a changelog line, and re-share.
The changelog is a list of one-line entries: date, version, what changed, why. 'v3, 2026-08-14, added the competitor-mention check, because two briefs missed an incumbent named in the notes.' It takes twenty seconds and it is the only reason I can answer 'why does the brief do that' six months later. It also makes rollback possible: when v4 turned out to be worse for a segment, the owner reverted to v3 in a minute instead of rebuilding it from memory.
Review is the gate between 'works for me' and 'shared with the org'. On Team and Enterprise, a member can share a skill org-wide, and admins can provision skills centrally so they are on by default for everyone. Both are powerful and both should sit behind a light review: the owner and one other person run the new version on five real inputs and read the output. Two people, five inputs, one afternoon, no committee. That is the whole review, and it has caught a retired value prop, a broken output format, and a prompt that quietly asked for a contact's phone number, which the security review would have had opinions about.
- Header of every skill file: name, version, owner, last reviewed, the Project it assumes.
- Changelog: one line per change, newest first. Date, version, what, why.
- Review before org-wide: owner plus one, five real inputs, read every output. Then bump the version and share.
Retirement: the library grows by pruning
The usage analytics dashboard on Team and Enterprise shows which skills members actually invoke, and the first time I read it, six of the eleven plays accounted for nearly all the runs and two had not been run in a month. Those two were good work. They were also debt, because every play in the library is a promise that it is current, and a play nobody runs is a promise nobody is checking. I retired both and the library got more trustworthy, which is the opposite of what I expected when I started collecting.
The retirement rule is quarterly and mechanical. The owner of each play looks at its runs for the quarter. Under a threshold we agreed in advance (ours is roughly one run a week across the team), the play is either merged into another, moved to an archive folder with its changelog intact, or kept with a written reason. Archived is fine; deleted is unnecessary. The point is that the live page only lists plays the team is actually running, so a new rep reading it sees what works, not what once seemed like a good idea.
The same quarterly pass checks the Projects for drift: is the positioning current, is the pricing right, has anyone uploaded a customer list that should not be there. Twenty minutes per Project. It is the maintenance I skipped for eight months, and it is the reason the follow-up went out with the dead value prop.
TipPut the retirement threshold on the library page before the first quarterly review. A threshold agreed in advance is a rule; one invented in the meeting is a fight.
The library page itself
The library is one page, and it lives wherever your team already reads: a Notion page, a Confluence page, a README in the GTM repo. It has a short header (the two-container rule, the naming rule, the retirement threshold, the prompt rule from the security review) and then a table grouped by funnel stage: play, one-line purpose, owner, current version, where to run it (app skill, Claude Code skill, routine), and the Project it assumes. Eleven rows for us. It fits on a screen.
Each row links to the skill file and its changelog. For app skills, that is the shared skill in the organization's directory; for Claude Code skills, it is the folder in the repo. There is no copy of the prompt text on the library page, ever, because a copy is a second version waiting to drift. The page points; the file is the truth.
New plays enter through a proposal, which is a message to the library owner with the play name, the job it does, the inputs, and a draft. Most proposals are a rep who did something clever and wants it to survive. That is exactly the instinct that created the forty-one screenshots, redirected into a place it can compound.
Where it goes wrong
The Slack channel as library. Prompts get seen once and lost forever, and every variant looks as canonical as every other. Keep the channel for proposals and discussion; the page and the files are the library.
Plays in Projects. Every Project ends up with its own copy of the pre-call brief, and they drift. Context in Projects, procedure in Skills, and be strict about it.
Team ownership. 'RevOps owns it' means nobody does. A person's name, in the file.
Sharing without review. A member shares a skill org-wide because it worked for them once, and forty people get a play that asks for data it should not or ships a story that is out of date. Owner plus one, five inputs, then share.
Collecting instead of pruning. The library hits fifty plays, reps cannot find anything, and they go back to their private notes. The dashboard tells you which ten matter. Archive the rest with their changelogs and let the page breathe.
The GTM version
For a sales and marketing team the library is small: a Project per role holding what is true right now, a dozen skills that are the plays, one page that lists them with owners and versions, a light review before anything goes org-wide, and a quarterly prune driven by the usage numbers. It is the same discipline you already apply to battlecards and sequences, extended to the prompts that now do a real share of the work.
The payoff is quiet. New reps find the right play in a minute. Positioning changes propagate in one edit. When a play misfires, the changelog says what changed and the owner says what to do. And the screenshots stop, because there is finally somewhere better for a good prompt to go. Which of your team's forty-one would make the first row?
How to set it up
Inventory what exists
Collect every prompt, Project, and skill the team uses: the Slack channel, the shared docs, the Projects list, the personal notes people will admit to. Group them by the job they do. You will find duplicates, orphans, and at least one that references something the business no longer says.
TipPaste the whole pile into Claude and ask it to cluster by job-to-be-done and flag near-duplicates. It turns a day of reading into an hour of deciding.
Split context from plays
For each role, write one Project page with the shared context: ICP, positioning, tone, current pricing, what not to say. Then take each repeated job and turn it into a skill file with a header (name, version 1, owner, last reviewed, the Project it assumes), the steps, and the output format. Delete the plays from the Projects.
Publish the library page
One page, where the team already reads. Header with the rules; table grouped by funnel stage with play, purpose, owner, version, where to run it, and the Project it assumes. Every row links to the file. No prompt text on the page itself.
Run the review and share org-wide
For each play, the owner and one other person run the current version on five real inputs (a real account URL, a real call transcript, a real inbound) and read the outputs. Fix, bump the version, add the changelog line, then share the skill with the organization or have an admin provision it centrally so it is on for everyone.
Schedule the quarterly prune
Put a recurring calendar hold for the library owner and the play owners. Pull the skill usage from the analytics dashboard, apply the threshold, archive or merge what fell under it, and check each Project for drift. Twenty minutes per Project, five per play. Write the date on the library page.
Frequently asked questions
What is a prompt library?
A single, owned place where a team's repeatable prompts and skills live, each with a name, an owner, a version, and a changelog, organized by the job it does. The opposite of a Slack channel full of screenshots. In Claude, the library splits across Projects (shared context) and Skills (repeatable plays).
Should prompts live in Projects or Skills?
Context lives in Projects: the ICP, positioning, tone, and what is true right now for a role. Procedures live in Skills: the step-by-step play with inputs and output format, invoked by name. A prompt copied into both drifts; keep each thing in one place.
How do we share skills across a Team or Enterprise plan?
Members can share a skill org-wide from Organization settings, and admins can provision skills centrally so they are on by default for everyone, with the option for users to toggle individual ones off. Shared skills appear in the organization tab of the directory. Put a light review (owner plus one, five real inputs) in front of either.
Who should own a play?
One named person, usually whoever runs it most. The owner accepts changes, keeps the changelog, watches usage, and retires the play when it stops earning its slot. The library owner (often RevOps) owns the conventions and the review, not every play.
How do we version prompts?
Like software. A version number and owner in the file header, a one-line changelog entry per change (date, version, what, why), and a review before the new version is shared. In Claude Code the skill is a folder in the repo, so every change is already a commit.
What is prompt debt?
Every clever prompt the team cannot find, reproduce, or fix: variants nobody reconciled, one-offs in personal notes, plays that still ship a retired story. It accrues faster than technical debt because writing a prompt takes a minute and nothing forces you to file it.
How many plays should the library have?
Fewer than you think. Most GTM teams run six to twelve plays that account for nearly all usage. Archive the rest with their changelogs intact. A library a new rep can read in a minute is the target; the usage dashboard tells you which rows earn their place.
How often should we prune?
Quarterly, mechanically. Pull skill usage from the analytics dashboard, apply a threshold agreed in advance, archive or merge what fell under it, and check each Project for drift. Agree the threshold before the first review so it is a rule and not a debate.
Sources & further reading
- Use skills in Claude (Claude Help Center)
- Skills for organizations, partners, the ecosystem (Anthropic)
- Browse skills, connectors, and plugins in one directory (Claude Help Center)
- Skills for enterprise (Claude Platform docs)
- View usage analytics for Team and Enterprise plans (Claude Help Center)
Claude ships fast. This page was last reviewed Sep 4, 2026; verify time-sensitive details against the official docs above before relying on them.