Prompts are work assets. Treat them like one.

Where prompt work goes to die

Chat history is a perfectly good record of conversations and a terrible home for work product. It's ordered by time. You search it by words you half-remember. The version you want is buried under its own follow-ups and corrections, four edits deep in a thread that starts with 'hey, quick question.'

Notes apps fail slower. You paste the prompt into a note, the note drifts down the list, and eight months later you have six notes titled some variation of 'prompts' holding slightly different copies. Which one is current? The one you edited last, which is also the one you mangled for a one-off task in March.

The part that bothers me most: you get better at writing prompts with experience, but the output of that experience doesn't accumulate anywhere. Every rebuild-from-memory loses a little precision. You end up an increasingly skilled craftsman whose work keeps washing away.

The text is the least interesting part

A prompt you use weekly isn't really text. The text is just the part you can see. Around it sits everything the prompt needs to do its job: the values that change each use (client, quarter, focus area), the files it works against (a style guide, a data export, a spec), and the record of what you tried before and how it went.

Keep a prompt in a note and you keep the text only. The variables are baked in as whatever you typed last time. The files live in your head. The history doesn't exist, so when you tweak the wording and the output gets worse, there's nothing to go back to.

In Linea I ended up calling this bundle the prompt's packet: a Blueprint holds the template, Variables are explicit fields, Context carries the files and remembered values, and Time Machine keeps the versions. The names matter less than the principle. Whatever tool you use, the bundle should travel together.

Boring practices that compound

A few things I've learned, mostly by doing them wrong first.

Name prompts after the work, not the format. 'Summary prompt' tells you nothing in six months. 'Client earnings risk analysis' or 'Code review: security pass' still mean something. If the name describes mechanics instead of purpose, you'll write a duplicate before you ever find the original.

Pull out a Variable when the structure stays and the value moves. The client name changes every use; the analytical framing shouldn't. And keep the last value visible. Your previous answer is usually your next answer, and seeing {{focus_area}} pre-filled with 'liquidity risk' is half the fill work already done.

Be stingy with permanent Context. The question isn't whether a file was relevant once. It's whether you'd attach it every single time without thinking. Style guide: yes. The one-off data export from April: no. A fat Context bundle is just a different way of losing things.

Version twenty-something

My everyday code-review Blueprint is twenty-some versions deep. Somewhere in the middle there's a version that was reliably right, and several after it where I 'improved' it into something worse. That used to be an unrecoverable mistake. Now it's a scrubber I drag backwards.

The only discipline this asks of you is marking a version when you notice it's working, before you keep fiddling. A star is enough. You don't have to remember why version twelve was good. You just have to know it was, and be able to get there.

I rate maybe half my versions. Half turns out to be plenty.

None of this is elaborate. Name the prompt, mark what varies, attach what it actually needs, star what works. The library grows out of work you were doing anyway.

I haven't gone scrolling through old chats for a lost prompt in a while now. That's the entire pitch.