Your team's AI coding prompts are inconsistent. Here's what that's costing you — and how a shared skills library fixes it.

When we analysed the first 30 days of Claude Code sessions across our 22-developer team, we expected to find the usual story: some developers using it heavily, some not at all.

What we didn't expect was this: 14 different prompts doing the same job.

Every developer had their own variant of "generate a Jest test for this function." Some were two sentences. Some were six paragraphs. One included a link to our internal testing conventions. Most did not. When we ran all 14 against the same function, the best output was markedly better than the worst — better coverage, correct mocking patterns, fewer fixes needed in review.

None of the developers with the better prompts had shared them. None of the developers with the worse prompts knew better versions existed. Everyone assumed they were doing it roughly the same way.

They were not.

---

The hidden cost of inconsistent prompts

The 14-variant Jest prompt problem isn't unusual. It's the default outcome when any team deploys AI coding tools without prompt governance.

The pattern plays out the same way every time:

1. Developer finds a prompt that works well for them
2. Developer saves it in a local file, a Notion doc, or just keeps it in their head
3. No one else knows it exists
4. Meanwhile, three other developers are using worse prompts for the same task — producing worse output, spending more time on fixes
5. The good prompt isn't even that good six months later — the codebase has changed, the framework has updated, and the original author long since moved on

We've started calling this prompt drift. Good prompts expire. Bad prompts persist. And without any measurement layer, you can't tell which is which until a PR review catches an obvious failure.

---

What we actually measured

After building our activity tracking layer and pointing it at the team, we ran a prompt audit across 668 sessions from the first 30 days.

What we found:

"Output quality delta" is a subjective measure — we had two senior engineers score AI outputs on a 5-point rubric without knowing which prompt produced them. The deltas are real but should be treated as directional, not precise.

The directional story is clear: for every task your team uses AI to do repeatedly, someone has figured out a substantially better way to ask for it than everyone else. That knowledge is currently trapped on their laptop.

---

Why the obvious solution doesn't work

The natural response to "our prompts are inconsistent" is to drop a CLAUDE.md file in the repo root with approved skills defined, announce it in Slack, and move on.

We did this. Here's what happened three months later:

• 6 of 11 developers in a given sprint had the CLAUDE.md skills configured correctly
• 3 had the file but were running outdated versions (they'd pulled the repo before the last update)
• 2 had local overrides that silently shadowed the org skills
• Zero developers were aware of the override rate problem — including the developers doing the overriding

Without measurement, CLAUDE.md governance is an honour system. And honour systems don't survive the second sprint.

---

The three things prompt governance actually requires

After running our own rollout and building the tooling to fix the gaps we found, here's what we think prompt governance actually needs:

1. A shared, versioned source of truth

Not a Notion page. Not a CLAUDE.md. A dedicated library where approved prompts (skills) live with full version history, authorship, and a clear distinction between "draft being reviewed" and "approved and live."

This sounds obvious until you think through what "version history" means in practice: you need to be able to roll back to v2 when v3 introduces a regression, and you need to know exactly who approved v3 and what their reasoning was. A Notion page doesn't give you that. A skills library does.

2. Deployment to every machine automatically

The CLAUDE.md problem isn't that the file is a bad format — it's that distributing updates requires every developer to pull changes. Approved skills should sync to developer machines the way dependencies sync: automatically, within minutes of an admin publishing a new version.

In our setup, a newly approved skill reaches every developer's Claude Code install within 3 minutes. That includes developers who haven't touched the repo in a week. The update doesn't require any action from the developer.

3. Measurement of whether skills are actually being used

This is the part nobody builds. Deploying a skill doesn't mean it's being used. Usage data requires knowing:

• Invocation rate — is this skill being called at all?
• Override rate — when the skill exists, what % of the time do developers write their own prompt instead?
• Per-developer override rate — not every developer overrides equally. A 40% team-level override rate might mean two developers are ignoring the skill and fifteen are using it religiously.

A high override rate isn't necessarily a compliance problem — it's usually a quality signal. If developers prefer their own prompt over the approved one, the approved one probably isn't good enough.

---

How AI suggestion changes the authoring problem

The other thing that makes prompt governance fail: writing skills is tedious.

Getting a developer to submit a prompt for review requires them to:

1. Recognise that their prompt is generalisable
2. Write it up in a format the team can use
3. Submit it for review
4. Wait for approval

This doesn't happen at scale. What does happen: developers accumulate good prompts privately, and the team never benefits.

We built around this by reversing the flow. Instead of asking developers to submit skills, we run a nightly AI analysis across all captured prompts. When it detects a high-frequency pattern — the same kind of task appearing 20+ times across multiple developers in a week — it surfaces an "AI suggestion pending" card in the admin view.

The card shows the admin:

• How many prompts triggered the suggestion
• How many developers were involved
• The weekly frequency
• The actual sample prompts that triggered it
• A draft skill generated from those samples

The admin reads the card, edits the draft if needed, and clicks "Approve." The skill ships to every machine within minutes.

This inverts the governance burden: instead of hoping developers remember to submit prompts, the system notices what they're already doing and brings it to the admin.

---

What happened when we deployed a governed skills library

After running the first 30 days as a measurement-only exercise, we built the skills library and ran it for 60 days. The comparison:

The PR cycle time drop is the number we track most closely. Faster review on AI-generated code is largely a function of output quality — reviewers spend less time fixing mocking patterns and edge cases that a better prompt would have caught.

The daily active developer increase is the number we didn't expect. When developers have a shared, high-quality skill to reach for, using AI for that task type becomes noticeably lower friction. Four of the seven developers who moved from occasional to daily use cited skill availability as a factor.

---

What a governed prompt library is actually for

It's worth being direct about this, because the pitch can make it sound like governance is primarily about compliance.

Compliance is one use case. If your organisation is working toward SOC 2 or ISO 42001 alignment, "what prompts are developers sending and who reviewed them" is a real audit question. A skills library with a full audit trail — every create, edit, approval, and AI generation attempt logged with actor and timestamp — answers that question.

But the more common use case is simpler: stopping the silent quality gap between your best prompt user and your worst one.

Your team has prompt expertise locked in individual heads. Some of it expires. Some of it never spreads. A governed library is the mechanism for extracting that expertise, reviewing it, keeping it current, and making it available to everyone — including the developer who joined last month and has no idea what's been figured out.

The ROI is hard to measure precisely (we're still working on it). The mechanism is clear.

---

The skills library in practice

If you want to understand what this looks like in practice, the Skills Library feature page covers the full lifecycle — from nightly pattern detection to the approval workflow to the per-skill usage counters.

The short version: approved skills are three-tier (built-in templates, org-wide, project-specific), versioned with full rollback, and synced automatically. AI generation from a plain-English description plus an optional reference URL takes about 60 seconds to produce a draft. The audit log captures every generation attempt — including failures and discards — so compliance can see the full picture of how AI was used to author team knowledge.

---

Frequently asked questions

What is prompt standardisation for engineering teams?

Prompt standardisation is the practice of establishing a shared, reviewed set of AI prompts — called skills — that all developers use for recurring tasks. Instead of each developer maintaining private prompts that drift in quality over time, the team maintains a versioned library of approved prompts. New team members inherit the best prompts on day one; when a better prompt is discovered, it replaces the old one for everyone simultaneously.

What is a Claude Code skills library?

A Claude Code skills library is a versioned collection of approved prompts automatically synced to every developer's Claude Code install. Skills can be org-wide (applying to all projects) or project-specific (scoped to a single repository). Each skill goes through an approval workflow before publishing, and the system tracks which developers use each skill versus writing their own prompts.

What is the difference between CLAUDE.md and a skills library?

CLAUDE.md is a configuration file Claude Code reads at session start. It can define skills, but relies on every developer pulling the latest version from the repo — there is no automatic distribution and no way to detect drift or stale configurations. A skills library adds automatic sync (new versions reach every machine within minutes), version history, approval workflows, and usage analytics that CLAUDE.md alone cannot provide.

How do you measure whether prompt governance is working?

Three metrics matter: unique prompt variants per task type (should fall from 7–14 to 1–3 as skills are adopted), team-level override rate (the percentage of sessions where developers use their own prompt instead of an approved skill), and per-developer override rate (which specific developers are overriding and for which tasks). In our rollout, we moved from 7–14 variants per task type to 1–3 within 60 days, and our override rate stabilised at 18%.

What does a high prompt override rate mean?

A high override rate means developers are preferring their own prompts over approved skills. This is primarily a quality signal: the approved skill probably does not fit the developer's workflow — it may be too generic, missing project context, or optimised for an older codebase version. The right response is to treat high override rate as a prompt improvement ticket, not a compliance issue. Learn what the developer's prompt does differently and update the approved skill to incorporate what works.

How quickly does a shared skills library reduce prompt inconsistency?

In our rollout, we moved from 7–14 unique prompt variants per task type to 3–4 within 14 days, and to 1–3 variants at 60 days. The fastest gains come from skills covering the highest-frequency tasks — unit test generation and PR review comment drafting accounted for over 40% of all AI sessions and saw the fastest adoption.

---

Related reading

• We tracked every AI coding session for 30 days — the activity tracking data this analysis builds on
• GitHub Copilot vs Claude Code — 30 days of data — the tool comparison where prompt depth emerged as a key differentiator
• 24% of our AI licences were never activated — what happens to the other side of the adoption problem
• AI prompt governance for Claude Code teams — the full Skills Library feature