Building a RBAC'd Prompt Library for a 20-Person Team
A role-gated prompt library works because it separates who can edit the shared building blocks everyone depends on from who can only edit their own work — that single structural decision is what keeps a growing library coherent. Get it right and new contributors can join without every addition becoming a risk to what everyone else relies on. Get it wrong, and either nobody can touch anything without asking permission, or everybody can touch everything and drift sets in almost immediately.
Why 20 people is the breaking point
Take a twenty-person team as a worked example: five prompt authors, a couple of people who maintain shared boilerplate, and the rest reading and running what's already there. At three or four people, an unbounded edit surface is fine — everyone knows everyone else's work, a bad edit gets noticed in minutes, and social convention does the job an access model would otherwise do. That doesn't scale linearly. Past roughly a dozen active contributors, "everyone can edit everything" stops meaning "everyone is careful" and starts meaning "every shared artifact has a dozen-plus people who can silently break it," with no structural reason any one of them would notice before the next person who depends on it does.
This is a structural argument, not an empirical one — there's no measured threshold in PromptHub's data and no research finding behind the number twenty. It's a convenient size for a worked example: big enough that informal coordination has clearly broken down, small enough that the fix doesn't require anything more sophisticated than four roles and one sharing layer. The same mechanism applies whether the real number is twelve or forty; what changes is only how urgently the gap is felt.
The fix isn't tighter documentation or a pinned Slack message asking people to be careful. It's making the two categories of work — shared building blocks everyone depends on, and an individual's own prompts — structurally different, so that editing one doesn't require the same permission as editing the other.
The four roles
PromptHub's role system draws exactly that line. Four roles govern who can touch what, and the boundary is enforced server-side on every request, not left to convention:
| Role | Shared components | Own prompts | Others' prompts | Typical fit |
|---|---|---|---|---|
| Admin | Create, edit, delete any component | Create, edit, delete, share | Edit or delete any prompt, including other people's public prompts | Whoever administers the library and can intervene on anyone's work when something needs fixing |
| Components Editor | Create, edit, delete any component | Create, edit, delete, share own prompts | No edit access | Whoever maintains the shared boilerplate — templates, standard instructions, reusable blocks — that the rest of the library is built from |
| Prompt Creator | View and export only, no create or edit rights | Create, edit, delete, share own prompts | No edit access | Contributors trusted to author their own prompts without needing to touch anything shared |
| Viewer | No access | Cannot create or edit; can view public prompts | No access | Anyone who consumes the library day to day without authoring anything in it |
Two things are easy to miss reading that table quickly. First, Admin and Components Editor both get full edit rights on components, but only Admin gets that same override on other people's individual prompts — a Components Editor who isn't the Admin still can't reach into someone else's private prompt, only into the shared components layer. Second, Prompt Creator retains view and export access on components even though it can't edit them, which matters in practice: someone authoring their own prompts still needs to read and reuse the shared building blocks, just not change them.
Mapping your org onto the roles
Standing up the model is a short, sequential exercise, not an ongoing governance program:
- Inventory what exists. Pull together every prompt currently in use — personal drafts, shared docs, anything pasted into a chat thread — before assigning a single role. You can't map roles onto work you haven't found yet.
- Decide which text is shared boilerplate versus individual work. A greeting template, a standard output-format instruction, or a compliance disclaimer used across many prompts belongs in a shared component. A prompt tuned for one person's specific task doesn't.
- Nominate the small group that owns shared components. These are your Components Editors — typically two or three people, not the whole team. Component ownership concentrated in a few hands is what keeps the shared layer coherent; spreading it across everyone recreates the drift problem the role model exists to prevent.
- Give everyone else authoring rights over their own work only. Most contributors should land as Prompt Creator: full control over what they write, no ability to accidentally break someone else's prompt or the shared components underneath it.
- Leave read-only access as the default for anyone who consumes but doesn't author. Stakeholders, reviewers, and anyone running prompts without writing them fit Viewer — they get everything they need to use the library without carrying edit risk they never asked for.
- Revisit the assignment when the team's shape changes. A Prompt Creator who starts maintaining shared templates should move to Components Editor; someone who steps back from authoring can move to Viewer. The mapping is a snapshot of current responsibilities, not a permanent label.
Sharing individual artifacts
Roles set the baseline, but day-to-day work also needs a way to hand one specific artifact to one specific teammate without changing anyone's role. PromptHub's chain-sharing layer covers exactly that case, with three permission levels: view, edit, and execute. The practical distinction that matters most is between edit and execute — granting someone the ability to run a chain is a meaningfully smaller grant than giving them the ability to change it. A teammate who only needs to trigger a working chain doesn't need, and shouldn't get, the ability to rewrite its logic; execute-only sharing makes that boundary explicit instead of relying on the recipient to self-restrict. View-only sharing is narrower still, useful when someone needs visibility into how a chain works without running or touching it at all.
This sharing layer sits alongside the role model rather than replacing it — a Prompt Creator with no components access can still be granted execute-only access to one specific chain someone else built, without that grant touching their role or anyone else's permissions.
What versioning buys you once access is bounded
Bounding who can edit what only pays off if a bad edit is recoverable. PromptHub keeps a full version history for every prompt: each edit is stored as its own version rather than overwriting the one before it, complete with a version number and a snapshot of the prompt's state at that point. Combined with a bounded set of people who can make the edit in the first place, that turns "something in the shared library changed and nobody's sure what" into "here's exactly what changed, who changed it, and what it looked like before" — attributable and reversible, not a mystery to reconstruct from memory.
This post is deliberately about standing up the access model rather than the day-to-day discipline of using version history once you have it — for the drift-specific treatment of that problem, see how to standardize support macros with prompt versioning.
Growing past 20
Access control keeps the library coherent as people are added; it doesn't by itself decide how many prompts, components, or executions the team can have. That's a separate dimension, governed by per-plan feature limits rather than by role. A twenty-person team that outgrows its current plan's limits needs a plan change, not a role change — the two are independent knobs.
The same role model extends past individual prompts, too. Chains built from multiple prompts inherit the same ownership and sharing logic described above, and programmatic access through the MCP server respects a caller's live role on every call rather than trusting whatever scope an API key happened to be minted with — so an access change made through the role model takes effect everywhere, not just in the dashboard UI. If you haven't stood up a multi-step chain yet, the complete guide to prompt chain design is the natural next read once the access model here is in place.
Where this leaves a growing team
None of this requires new tooling once the roles exist — it's an inventory-and-assign exercise, not a project with its own timeline. A twenty-person team that has gone through the mapping above ends up with a small set of people who own shared components, a larger set who author their own work without risk to anyone else's, and a read-only default for everyone who just needs to use what's already there. If your team is still figuring out where a shared prompt library fits for customer support workflows or for packaging AI workflows for client agencies, both start from the same four-role foundation described here.