Naming Conventions for a Team Prompt Library

TL;DR: A prompt naming convention only has one real job on a team library: make a flat list of shared prompts scannable without anyone opening each one. Keep the name to subject plus variant, push model and status into tags, keep version numbers out of the title entirely, and pick a casing rule once because nothing in the product enforces one for you.

Why Does a Team Prompt Library Need a Naming Convention at All?

Because of a specific, unglamorous fact about how team sharing actually works here: folders in Prompt Architects are owner-only. A teammate never sees your folder tree and you never see theirs, enforced at the database layer rather than just hidden in the UI. What a teammate sees instead, when you share a prompt to the team, is a flat, read-only Team view, not a shelf your folder structure fits into.

That single fact changes what a naming convention is for. On a personal library, a mediocre name is forgivable because a folder is doing most of the finding for you. On a shared team view, there is no folder to fall back on. The name is the only structure a teammate gets, which is exactly why it earns its own convention rather than being an afterthought bolted onto whatever taxonomy the rest of the library uses. (If you haven't decided that wider taxonomy yet, folders vs tags vs facets and who owns the category list is covered in full in How to Structure a Prompt Library That Scales to 1,000; this post picks up after that decision is made.)

What Actually Goes Into a Good Prompt Name?

Two things, in this order: the subject, then the variant that distinguishes it from its siblings. Nothing else.

• Subject first. What is this prompt actually for? "Cold Email Opener," not "Sales Prompt #4."
• Variant second, only if more than one version of that subject exists for a real reason. "Cold Email Opener - Series A CTOs" distinguishes it from "Cold Email Opener - Enterprise IT," which is a real difference a teammate needs to see at a glance.

Everything past that point is metadata wearing a costume. Prompt Architects already gives you two fields built for exactly this: category, a single value from a fixed list (with room for one custom label if nothing fits), and tags, any number of free-form labels. A name that reads "Cold Email Opener - Series A CTOs - Sales - Outbound - Q3" is doing the category field's job and the tag field's job inside a string meant for neither, and it's the single most common naming mistake on a team library: cramming attributes into the name because the name is the first field anyone sees, rather than trusting the fields built to hold them.

Should the Model or Platform Live in the Name?

Only when you genuinely maintain separate variants per model, and even then, a tag beats a suffix. "Cold Email Opener (GPT-5)" looks precise the day you write it and becomes actively misleading the day you also start running it on Claude or Gemini without changing a word, because the prompt still works fine and the name is now just wrong. A tag like model:gpt-5 or model-agnostic carries the same information without embedding a claim in the one field a teammate reads first and trusts most.

The same logic applies to status words like "final," "approved," or "DO NOT TOUCH." They read as instructions but they're really state, and state belongs in a tag you can filter on and audit later, not permanently welded into a title string nobody remembers to update.

Where Should Version Numbers Live?

Not in the title, if you can help it. Prompt Architects has no dedicated version field on a library item, which means a "v3" or "FINAL_v2" living in a title is a workaround for a field that doesn't exist, not a naming choice. The workaround has a real cost: it makes the name longer, it invites the same subjective drift every "final_final_v2" filename convention has always invited, and it competes for the hundred-character budget the title actually has to work with.

The better workaround is a tag, not a title suffix: tested-2026-09 or draft does the same job, sorts and filters cleanly, and doesn't force every reader to parse a version number before they get to what the prompt actually is. If your team needs real version history rather than a status label, that's a genuinely different problem than naming, and outside what this post covers.

Good:  Cold Email Opener - Series A CTOs
Good:  Support Reply - Refund Request
Bad:   Cold_Email_v3_FINAL_GPT5_DoNotEdit
Bad:   Sales Prompt #4

Does the Name Even Matter If Search Already Covers Keywords?

Less than you'd think, and it's worth being precise about why, because it changes what a good name is actually for. Search on the library matches the title, the content, and the tags together, not the title alone, so a keyword buried in the prompt's body is already findable without living in the name too. That's genuinely good news: it means a naming convention doesn't have to double as a keyword-stuffing exercise, and a short, honest subject line loses nothing on searchability that content search wasn't already covering.

What search doesn't do is scanning. A search box answers "find me the prompt about X" when you already know X. It does nothing for the more common moment on a team library, someone opening the shared Team view and scrolling to see what's available before they know exactly what they're looking for. That's a browsing problem, not a retrieval problem, and browsing is exactly what a name is for: not to be matched by a query, but to be read and understood in the half-second it takes to scan past it in a list of thirty other prompts.

Does Casing Actually Matter in a Prompt Name?

Less than most style guides insist, but it isn't nothing either, and the reason is specific to this product rather than a general writing-style opinion. Category matching folds near-duplicates together automatically and case-insensitively behind the scenes, so a typed category that only differs by casing from an existing one gets treated as the same category. The title field gets no such favor. "Cold Email Opener" and "cold email opener" are two distinct strings for anything that compares them exactly, which matters the moment your library grows past the size where every teammate has seen every name at least once.

That asymmetry is the actual argument for picking a casing rule, not a preference for Title Case over sentence case on its own terms. Either convention works fine; what breaks a library is three teammates each defaulting to whatever their fingers typed that day, because now visually identical prompts sort differently, search results feel inconsistent, and nothing in the product is going to notice or fix it for you. Pick one, write it in the same place you wrote the naming pattern, and treat it the same way: a rule the owner enforces at share time, not a suggestion.

How Do Two People Avoid Inventing Different Conventions in Parallel?

The same way you'd stop two people inventing two different folder trees: one person owns the convention, in writing, and everyone else follows it rather than extending it on the fly. This is the same governance principle our piece on prompt library structure applies to the wider taxonomy, and it applies just as directly to naming specifically, because a naming pattern with no owner degrades exactly the same way an unowned folder tree does: two reasonable people making two reasonable, incompatible choices, independently, at the same time.

The practical version costs almost nothing to set up. Write the pattern down somewhere every teammate can find it, in the same doc where you already keep your category and tag list if you have one, and treat any name that breaks the pattern as a single item to fix, not a precedent for a new exception. The moment "well, this one's different" becomes a category of prompt rather than an edge case, the convention has already stopped being a convention.

How Do You Migrate an Existing Library to a New Convention?

Slower than you'd like, and not through the import feature, which is the mistake worth heading off directly. Renaming a batch of items by exporting them, editing the titles in the JSON file, and re-importing does not work the way it looks like it should: import dedupes against your existing items by title, content, and negative prompt together, so a changed title produces a new dedupe key. The result isn't a rename, it's a second copy of the same prompt sitting under the new name, with the original still there under the old one.

That leaves one honest path: renaming items one at a time, in place, through the edit screen. For a library in the low dozens, that's an afternoon. For a genuinely large library, the practical move is triage rather than a single pass: rename the prompts your team actually opens every week first, since those are the ones a bad name costs you the most on, and let the long tail migrate opportunistically as each item gets touched for some other reason anyway.

A short, sequenced pass beats a big-bang rewrite for the same reason most migrations do: it keeps the library usable the whole time instead of half-renamed and confusing for a week.

1. Export your team's shared items first (own + team-shared), so you have a
   dated snapshot of the old names before you touch anything.
2. Sort by last-used or last-edited if you can; rename the top 20% first.
   That's usually 80% of what anyone actually opens in a given week.
3. Fix names in place through the edit screen, not through delete-and-recreate.
   A delete loses the item's history and any team-share status it already had.
4. Move anything that was smuggling model, status, or version into the title
   out into a tag while you're already in the item editing it.
5. Leave everything else alone until it's touched for some other reason.
   A half-migrated library with a written convention beats a fully-migrated
   one nobody remembers the rule for six months later.

Skip step one if the library is small enough that "before" doesn't matter to you, but for anything a team actually depends on, having the export sitting somewhere means a bad rename is recoverable rather than a permanent loss of whatever the old title used to communicate.

A Naming Pattern by Team Size

Notice that column two, not column three, is where the real jump in rigor happens. A five-person team already has enough parallel editors that an unowned naming pattern starts drifting within weeks, well before the library itself is large enough to feel unmanageable. Fix the convention at team size two, not at prompt count one thousand.

For the marketing-team version of this same discipline applied to a full playbook rather than just names, see The Marketing Team Prompt Playbook, and for how one founder's naming and reuse habits evolve as a library goes from personal to shared, see The Founder's Prompt System.