Govern the Prompt and Asset Library Like the Codebase It Now Is

Workflow area: Org Design & Change · Tier: Core · Hands-on time: ~30 minutes

Six months into any serious AI adoption, the org's most valuable AI asset is no longer the tool subscription — it is the accumulated craft: the incident-review prompt that took eleven iterations to get right, the context file that finally made the assistant useful in the legacy monorepo, the agent config that runs the release checklist. Left ungoverned, this craft has the shelf life of a Slack scrollback. Worse, some of these artifacts are load-bearing in ways prompts never used to be: a rules file quietly shapes every diff the team merges, and an MCP server is running code with credentials. Assets that shape production code and touch internal systems have earned the same treatment as code — review, versioning, ownership — because that is functionally what they are.

When to use — and when not to

• Use it once the same prompt has been rewritten from scratch three timesthat is the signal the craft exists but the infrastructure doesn't.
• Use it the day the first MCP server or agent config appearsthese are executable integrations, and retrofitting governance after ten of them are running is much harder.
• Use it as the landing zone for upskilling artifactspb-46's applied projects and pb-43's champion patterns need somewhere durable to accumulate.
• Skip the heavyweight process for personal experiment promptsgovernance covers shared assets; an engineer's private prompt stash needs no review board, and trying to govern it just drives sharing underground.
• Don't build a wiki graveyardif the library is a documentation site nobody's tools read from, it will rot exactly like every other wiki; the library must live where the assets are consumed (the repos, the tool configs).

The recipe

1. 1.

   Create the repo and make it the single source. One Git repository (or a clearly-marked area of the monorepo), structured by asset type, with the same access model as your code:

   Copy

   ai-assets/
     prompts/          # reusable prompt templates, by workflow
       incident-review.md      (owner: @priya, v3, reviewed 2026-07)
     rules/            # CLAUDE.md, rules files, style constraints
       backend-monorepo/CLAUDE.md
     agents/           # agent definitions and configs
       release-checklist-agent/
     mcp/              # MCP server registry — see step 3
       REGISTRY.md
     evals/            # eval suites that verify the above
   CONTRIBUTING.md     # review norms, template, sunset policy
   

   Every asset carries a header: owner, purpose, last-verified date, and which model/tool it was validated against. Git gives you versioning and blame for free — that is why the library is a repo and not a Notion page.

2. 2.

   Set review norms proportional to blast radius. Not everything needs the same rigor, and saying so explicitly is what keeps contribution friction low:

   • •
     Prompts and templates — lightweight PR review by any maintainer: does it work, is it clear, does it leak anything (credentials, client names, internal URLs) into a reusable artifact?
   • •
     Rules files and CLAUDE.md — reviewed by the owning team's lead, because a rules file is a standing instruction that shapes every future diff in that repo; a bad line ("prefer speed over tests") compounds daily.
   • •
     Agent configs — code review plus an explicit statement of what the agent can touch and its permission scopes (pb-30's autonomy ladders apply).
   • •
     MCP servers — the strictest tier: security review before registration, because an MCP server is code running with access to internal systems.
3. 3.

   Run the MCP registry as an allowlist, not a catalog. The registry lists every approved server with: what it connects to, what credentials it holds, who owns it, and its review date. The norm to establish early, while it is cheap: engineers install MCP servers from the registry; adding a new one — public or homegrown — goes through the review lane first. Unvetted MCP servers from the wild are the current era's curl | sudo bash, with a supply chain nobody is watching yet.

4. 4.

   Wire the library into daily work, or it dies. Distribution is the step that separates libraries from graveyards: rules files live in the repos they govern (synced from the library or simply canonical there); shared prompts ship into the tools people use (Claude Projects, slash commands, snippets); new-joiner onboarding includes "clone ai-assets, wire the configs" on day one; and the CoP session (pb-46) reviews one contribution per meeting. Measure consumption, not size — a library of 30 assets with heavy reuse beats 300 entries nobody pulls.

5. 5.

   Sunset on a schedule, because prompts rot faster than code. Every asset's last-verified date gets a quarterly sweep by its owner: still works on current models? still reflects current standards? Assets failing the sweep get fixed or moved to archive/ — visibly, so nobody builds on a dead pattern. A model upgrade is a mass-expiry event: the sweep after a major model change is mandatory, not optional, because a prompt tuned around an old model's weaknesses can silently misfire on the new one. Where you have evals (and for load-bearing assets, you should — pb-46's artifacts), the sweep is a CI run instead of an opinion.

Make it yours

• Startup or small team: one repo, one maintainer, PR review by whoever's around — but keep the MCP allowlist rule at full strength from day one; small teams are exactly where an engineer wires a random server to the production database "to try something."
• Mid-size org: federate — each team owns its area of the library with local maintainers, a small guild owns CONTRIBUTING.md and the MCP registry, and cross-team reuse gets celebrated in the CoP; resist central curation of prompt content, which just recreates the wiki bottleneck with extra steps.
• Large org or GCC: the library becomes real infrastructure — org-level registry with security review SLAs for MCP servers, client-boundary rules in a GCC (account-specific assets segregated per client contract, no cross-account prompt reuse where confidentiality applies), and the sunset sweep automated against eval suites; at this scale the library is also your audit answer to "what AI instructions shape your delivery?", so treat its history as evidence you'll one day be glad exists.

Quality check

• Every shared asset has a live ownerorphaned assets fail the quarterly sweep by definition; an owner who left the team is an orphan with extra steps.
• Rules-file changes get real reviewsample the last five CLAUDE.md merges; rubber-stamped standing instructions are the highest-leverage unreviewed text in your org.
• The MCP registry matches realityspot-check two engineers' actual tool configs against the allowlist; drift here is a security finding, not a tidiness issue.
• Consumption is measurable and nonzeropulls, syncs, or slash-command usage; a library nobody consumes is documentation cosplay.
• The post-model-upgrade sweep actually rancheck the last-verified dates after the most recent model change; if they predate it, the library is asserting freshness it doesn't have.