Naming Prompts So You Can Find Them Later

TL;DR: Naming a prompt well is a retrieval problem, not a filing problem: the goal is that future-you, having half-forgotten this prompt exists, can find it in under ten seconds. That takes three layers doing different jobs — a title, a description, and a couple of tags — plus a habit of fixing bad names in one pass instead of one regret at a time.

Why Do Good Prompts Still Get Lost?

Because the prompt working well and the prompt being findable are two separate problems, and only one of them feels urgent while you're writing it. You save a prompt the moment it produces something good, name it whatever comes to mind in the next four seconds, and move on. Six weeks later you remember writing something like this, roughly, but the title in front of you says "Email 2" and gives you nothing to go on.

This guide is about the second problem specifically: how you label a prompt so it survives contact with your own memory later. It assumes you already have somewhere to put prompts, a folder, a tool, a notes file, and a library small enough that browsing is still plausible: a few dozen prompts up to somewhere around a hundred and fifty. If you're past that and managing hundreds or thousands across clients or a team, the naming convention here still applies, but you also need the folder-and-tag architecture from organizing 1000+ prompts, which is a bigger job than naming alone can solve. This page is deliberately narrower: not where a prompt lives, just what it's called.

What Actually Makes a Prompt Name "Findable"?

A name is findable when it answers the question you'll ask yourself later, not the question you were thinking about when you saved it. At save time you're thinking about the output you just got. Weeks later, you're thinking "what do I call the thing I use for X," which is a completely different mental search than "what did this particular output look like."

That gap is why so many saved prompts end up named after a fleeting detail from the moment they were created — the client, the exact phrasing of the request, an inside joke about how badly the first draft came out — instead of the durable, repeatable shape of the task. A name built around the moment expires with the moment. A name built around the task keeps working for as long as the task recurs.

It also compounds in a specific direction: the more a library grows, the more two names have to differ from each other to stay useful, and the more a moment-based name collides with something else you saved around a different moment that happened to feel similarly urgent at the time. Ten prompts named after how they felt to write is manageable. Fifty is a library where half the titles could describe half the prompts.

Does Naming Work the Same Way Across ChatGPT, Claude, and Gemini?

Mostly yes, and that consistency is worth protecting on purpose. If your library serves more than one AI tool, the same verb-object-audience pattern should describe the task regardless of which model ends up running it, because the task itself, rewrite this, summarize that, review this, doesn't change with the platform. What changes is occasionally worth a tag, not a rewritten title: a prompt tuned specifically for one model's quirks is still the same task, just tagged with which model it was last verified against.

The failure mode to watch for is naming a prompt after the tool instead of the task, "Claude prompt for emails" instead of "Draft client check-in email," because that buries the one piece of information you'll actually search for later, what the prompt does, underneath the one piece that rarely matters when you're trying to find it again.

The Three Layers: Title, Description, Tags

Most tools that let you save a prompt give you three separate fields, and most people only fill in one of them. That's the single biggest fixable mistake in personal prompt naming: using the title to carry all three jobs at once, which makes it too long to scan and too vague to disambiguate.

Split the work this way and each field earns its place. The title tells you what kind of prompt this is. The description tells you why this prompt and not the other three that look similar in a title-only list. The tags let you filter across prompts that have nothing else in common except one shared attribute, like "everything I've tested this month" or "everything tuned for Claude specifically."

What Makes a Prompt Title Actually Work?

Lead with a verb, name the thing the verb acts on, then say who or what it's for. [verb] [object] [audience or context] is the pattern, and it works because it puts the most information-dense word first: a verb tells you the shape of the action before you've read the rest of the sentence.

Names that work:

• Rewrite hero copy for skeptical buyers
• Summarize support thread for engineering
• Draft investor update for a board that reads on a phone
• Review migration script for a junior reviewer

Names that don't:

• Email v2
• Helper
• Landing page prompt
• Copy (1)

The difference isn't length, it's information. "Email v2" is four characters shorter than "Draft cold outreach for a Series A CTO" and tells you nothing at all. A name that reads like a sticky note to yourself, written by someone who assumed they'd remember the context, is the exact failure mode this whole system exists to prevent.

How Do You Fix a Library Full of "v2," "Final," and "Untitled"?

In one deliberate pass, not one regret at a time. Renaming as you happen to stumble across a bad name means the worst-named prompts, the ones you never open because you can't tell what they are, never get fixed at all. That's backwards: those are exactly the ones costing you the most.

Sort your library by last-used date and work from the top. Your ten most-used prompts are worth five minutes each today, because you'll benefit from the fix every single time you reach for them from now on. Everything below that line can wait for a slower afternoon, or, honestly, might not be worth renaming at all if you haven't opened it in months. A prompt with a bad name that you never use isn't a naming problem. It's a decluttering one.

A useful trigger while you rename: if you find yourself writing a title, pausing, and thinking "wait, do I already have one of these," that's the moment to check for a near-duplicate before you save the new title, not after.

How Do You Handle Near-Duplicate Prompts?

Add the detail that actually differs, not a version number. "Cold email for Series A CTO" and "Cold email for seed-stage investor" are two different, legitimately reusable prompts that happen to share a shape. "Cold email v1" and "Cold email v2" are the same prompt with no information about which one is current, which is worse than useless because it actively points you at the wrong one half the time.

The test: if you deleted the numeral, would the two names become identical? If yes, they're not disambiguated, they're just numbered, and numbering is a signal that says "these differ" without saying how. Say how instead. The qualifier that actually distinguishes two similar prompts, the audience, the platform, the output format, belongs in the title. A version history of the same prompt improving over time belongs somewhere else entirely, which prompt versioning for developers covers if you're tracking that formally.

A concrete pair, worked through: "Cold email for Series A CTO" and "Cold email for seed investor" are both keepers, because the audience genuinely changes what the prompt says. "Cold email draft" and "Cold email draft 2" are not, because nothing in either name tells you what's actually different, and six months from now you'll open both to find out, which is exactly the extra step good naming is supposed to remove.

Should You Rename a Prompt After You Improve It?

Only when the change alters what the prompt does, not just how well it does it. Tightening a constraint, adding a word limit, fixing a phrase that kept producing a chatty preamble: none of that changes what the name promises, so the name doesn't need to change either.

A rename earns its keep when the prompt's actual job shifts: it used to produce a paragraph and now produces a table, it used to target one audience and you've generalized it to three, it used to assume one platform and now works across several. At that point the old name is actively misleading, not just imprecise, and a search that trusts the name will miss the prompt entirely.

A 30-Second Naming Recipe You Can Use Every Time

The whole system, as a repeatable habit rather than a rule you have to remember:

1. Lead with a verb: Rewrite, Draft, Summarize, Review, Generate.
2. Name the object: hero copy, support thread, migration script.
3. Add who or what it's for: skeptical buyers, engineering, a junior reviewer.
4. In the description field, add the ONE detail that would tell this
   apart from a near-identical prompt: a word limit, a tone, a constraint.
5. Add at most two or three tags: the model it's tuned for, its status
   (tested / draft), and its output shape (table, list, prose).

That's five steps and well under thirty seconds once it's a habit. The habit is the point: a naming system you have to consciously think through every time is a system you'll abandon by the third week. One that fits in the same five seconds you already spend deciding whether to save the prompt at all is one you'll actually keep using.

What Does Prompt Architects Do With Titles, Descriptions, and Tags?

Every saved prompt carries all three fields this guide describes: a title, a description, and tags, searchable across the library and, once you've named something well once, reusable across ChatGPT, Claude, and Gemini through the same Chrome extension rather than three separate naming systems in three separate tools. Naming is only relevant once there's something to name, though, and that's a Pro-and-up boundary: the free plan is five architected prompt generations a day with no saved library at all, per the pricing page. If you're deciding whether a given prompt is even worth the naming effort before you commit it to a permanent slot, that's really a separate, upstream question from this one: building a personal library from scratch covers that groundwork, and the decision rule for templating a task at all covers whether it's worth a saved slot before you ever get to naming it.