How to Organize Your Prompts: A System That Scales

Why this matters more than it looks

A disorganised prompt collection has the same problem as a disorganised codebase: every change costs more than it should, you accidentally rewrite the same thing twice, and the best work gets lost inside the worst work.

People typically notice the cost only after they have fifty prompts. By that point you are searching by guessing, and the system you wished you had set up earlier is now a refactor instead of a default.

This guide is the system you should set up before you reach fifty.

Decide what a prompt is, before you store it

The first decision is what counts as a prompt worth keeping. A useful filter:

• Keep it if you would run it again, or if it produced an output you might want to recover.
• Throw it away if it was a one-off exploration with no reuse value.
• Refactor it if you ran something similar three times in a row — that is the signal to turn it into a reusable template.

About two thirds of your raw prompt history will fall into the third category if you are doing real work. Most "prompt libraries" fail because they preserve everything.

A folder structure that holds up

The structure below works for individuals and small teams. It is intentionally shallow.

prompts/
  workflows/        # multi-step, repeated end-to-end processes
  templates/        # single reusable prompts with placeholders
  experiments/      # in-progress, not stable yet
  archive/          # used to work, no longer relevant

Three rules make this scale:

1. A prompt lives in exactly one folder. "Templates that are also workflows" do not exist. Pick one.
2. experiments/ is a halfway house. When a prompt has been used reliably five times, promote it to templates/ or workflows/. If it has not been touched in a month, move it to archive/.
3. archive/ is not deleted. It is the search index for "have I done this before?" The cost of keeping it is near zero.

If you have more than ten templates, add one level of grouping inside templates/ (by audience: writing/, research/, code/). Going deeper than two levels almost always backfires — you start filing things in the "wrong" folder and giving up on the structure.

Naming conventions that survive

Names matter more than folders for retrieval. A good prompt name answers two questions at a glance: what does it produce, and for whom?

Bad: summary-prompt.md, v2-better.md, untitled.md.

Good: weekly-status-summary-for-eng-leads.md, pr-review-security-focus.md, competitor-feature-brief-from-url.md.

Three conventions worth adopting:

• Verb-object-modifier. Start with the output, then the subject, then the constraint. "summary-pr-security-focus" is easier to skim than "security-focused-pr-summarisation".
• No version numbers in filenames. Version history belongs inside the prompt (a "version notes" block) or in your git log, not in the name.
• Hyphens, lowercase, no spaces. Trivial, but searching is much easier when you do not have to remember capitalisation.

Metadata: the small effort that pays back the most

For any prompt worth keeping, store three things alongside it:

1. Purpose. Two sentences. Why this prompt exists, who runs it, when.

2. Inputs and outputs. What you paste in, what shape comes out. Even a couple of bullet points is enough.

3. Known failure modes. The ways this prompt sometimes fails, and the workarounds. This is the most valuable section after a few months. It saves you from re-discovering the same bug.

A simple template:

# weekly-status-summary-for-eng-leads

Purpose: Turns my Friday notes into a status update for engineering leadership.
I run this every Friday at 4pm.

Inputs:
- Plain-text notes from the week (bullet points, any order)

Outputs:
- Three sections: Shipped, In Progress, Blockers
- Each section ≤ 4 lines
- No emoji

Known failure modes:
- Sometimes invents progress on items I did not mention. Fix: add
  "Only mention items present in the input. Do not infer."

If a prompt does not deserve this much documentation, it probably belongs in experiments/ or archive/, not in your main library.

Tagging vs folders

For small libraries, folders are enough. Once you cross fifty prompts, tagging beats folder hierarchy because a prompt often belongs to multiple categories. Use tags like audience:eng, tool:figma, stage:draft. The exact tags matter less than picking a small set (under fifteen) and using them consistently.

The danger with tags is unlimited proliferation. If you find yourself with thirty rarely-used tags, consolidate. Tags only help retrieval if you can remember them.

Promotion and pruning rituals

The most underrated part of a prompt system is the regular cleanup pass. Without one, experiments/ becomes the new archive/.

A practical rhythm:

• Weekly (5 minutes). Move anything in experiments/ that hasn't been touched for two weeks to archive/. Move anything used reliably to templates/ or workflows/.
• Monthly (15 minutes). Look at the top five most-used prompts. Update their "known failure modes" block. Improve the prompt itself if a pattern of failures has appeared.
• Quarterly (30 minutes). Re-read names and tags. Consolidate anything that has drifted.

This costs you about two hours a year and roughly doubles the half-life of a prompt library.

What this looks like in PromptPlan

If you are using PromptPlan, the structure above maps directly: folders in the sidebar correspond to the top-level groups, templates and workflows live as first-class objects, and the per-note fields cover the metadata block. The rituals are the same regardless of tool — the tool only removes friction.

The point is not which app you store prompts in. The point is that you store them like you mean to use them again.