Building a prompt library you actually reuse, instead of scrolling a chat history

Everyone who generates regularly has had the experience: a prompt that produced exactly the right lighting, three weeks ago, in a conversation about something else. You remember it existed. You do not remember the wording, and scrolling back through a chat history to find it costs more than rewriting it badly.

So you rewrite it badly. And the knowledge you built never compounds — every project starts roughly where the last one started, which is why people plateau at a level well below what their experience should give them.

The fix is small and boring, which is why almost nobody does it.

The instinct is to organise by client or project, because that is how the work arrived. It is useless for retrieval — six months later you have no memory of which job had the good backlit shot.

Organise by the problem the prompt solved:

prompts/
  lighting/single-hard-key.txt
  lighting/overcast-flat.txt
  composition/lower-third-empty.txt
  surface/matte-bone-seamless.txt
  camera/slow-push-static-subject.txt
  constraint/product-preservation.txt

Now the search matches how you will actually think: 'I need that hard key thing'. And because the units are blocks rather than whole prompts, they compose — a new prompt is assembled from four files rather than written from nothing.

Each entry needs three things:

# single-hard-key
Single hard key from upper left, no fill,
one clean shadow falling to the right.

model: worked on Qwen 2512, Flux, Seedance
fixes: flat shapeless default lighting
note: 'no fill' is doing most of the work here

The last line is the valuable one. Six months later you will not remember which four words mattered, and the note is what lets you adapt the block rather than paste it blindly.

Record failures too, briefly. A file saying 'aperture values do nothing, do not bother' saves you re-discovering it.

The failure mode is accumulation: every prompt you ever wrote, saved, until finding something is as hard as scrolling the chat log you were escaping.

Add an entry only when a block has worked twice. First time it is luck; second time it is knowledge. This keeps the library small enough to read.

Delete entries when a model change makes them wrong. An outdated block that silently stops working is the worst thing in the folder, because you will paste it, get a bad result, and blame something else.

Twenty good blocks beats two hundred saved prompts. The whole point is that you can hold the contents in your head and reach for the right file directly.

Save one representative output alongside each block, in the same folder. Text alone is ambiguous — 'soft overhead light' means something specific once you see what it produced.

This also makes the library reviewable. Opening the folder and looking at twenty thumbnails tells you in seconds what your vocabulary actually spans, and where the gaps are. Reading twenty text files tells you nothing.

It doubles as a style reference store, which is where most of these images will end up being used anyway.

A complete prompt from two models ago is usually worthless. A block that names a lighting setup, plus a note about which part of it was load-bearing, is still useful — you adapt the wording and the concept transfers.

That is why the library is organised around problems. Problems are stable; solutions are versioned. Storing solutions without naming the problem they solved is what makes an archive rather than a library.

Start with five files. It takes ten minutes and it is the difference between six years of experience and one year of experience repeated six times.