I Built a 400-Prompt Library and Used Maybe 12 of Them
Six months into building my prompt library, I had 412 prompts across 11 folders, a color-coding system I'd spent an embarrassing amount of time designing, and a Notion database with tags like "creative," "technical," and "misc" — which, when you think about it, means I had two categories. I was opening a blank ChatGPT window and typing from scratch every single day. The library was a museum I never visited.
Mistake #1: Organizing Around Topics Instead of Triggers
My first instinct was to organize prompts the way you'd organize a filing cabinet: by subject. Writing prompts here, coding prompts there, research prompts in a third pile. It made logical sense and was completely useless in practice.
The problem is that when you need a prompt, you're not thinking "I need a writing prompt." You're thinking "I need to turn this messy bullet list into a stakeholder email in the next ten minutes." The mental model that gets you to your prompt library is a situation, not a category.
I rebuilt the whole thing around triggers — the specific contexts that make me reach for a prompt. Not "writing" but "I have rough notes and need a polished draft fast." Not "research" but "I'm starting a topic I know nothing about and need a fast foundation." Not "coding" but "I have a bug and I've been staring at it too long."
When I switched to trigger-based organization, my usage rate went from almost zero to something I actually track. The prompt you can find in two seconds is worth ten you have to hunt for.
Mistake #2: Writing Prompts in the Moment, for the Moment
Every time I had a good prompt interaction, I'd copy the prompt and paste it into my library. Seemed efficient. It was actually just hoarding.
Prompts written in the moment are too specific to be reusable. They contain context that was true once — the project name, the particular audience, the deadline pressure that shaped how I phrased things. When I came back to them later, I'd have to spend two minutes re-reading and mentally stripping that context out before I could adapt it. At that point I was almost better off writing fresh.
The fix was to do one extra step before saving: abstract it. Take the successful prompt, identify the pattern it represents, and rewrite it as a template with explicit variables. [AUDIENCE], [GOAL], [CONSTRAINT]. Yes, it takes an extra three minutes. Those three minutes compound across every future use.
The best prompts in my library now read like small programs with clear inputs and predictable outputs. They're slightly ugly to look at and extremely fast to deploy.
Mistake #3: Treating Every Prompt as Worth Keeping
I had a prompt graveyard. Prompts I'd used once, gotten decent results, and never touched again. Prompts for tools I no longer used. Prompts I'd saved "just in case" for a use case that never materialized.
The graveyard had a real cost. Every time I scrolled through my library, I was processing dozens of entries that weren't relevant. The cognitive load of managing a large library of low-quality prompts exceeded the value of having the library at all.
I started applying a brutal rule: a prompt doesn't stay unless it has been used at least three times or solves a problem I hit monthly. Everything else gets deleted, not archived. Archived means you'll look at it again. You won't. Delete it.
My library went from 400+ entries to 64. My usage went up, not down. The prompts that survived were the ones that were actually doing work.
Mistake #4: Ignoring Prompt Decay
This one cost me real time. A prompt I wrote to extract structured data from a certain format worked beautifully for four months, then started producing inconsistent results. I blamed myself — changed my inputs, tried different phrasing, got frustrated. Took me two weeks to realize the model I was using had been updated and the original prompt's assumptions about response formatting were stale.
Prompts decay. Models change, APIs update, your own use cases evolve. A prompt library without a maintenance loop is a prompt library that quietly starts lying to you.
I now put a review date on every prompt — three months out by default, one month for anything that touches a specific model version or API behavior. It's a five-minute calendar reminder that saves hours of confused debugging. When the reminder fires, I spend two minutes running the prompt on a test case and verifying the output still matches expectations. Most of the time it's fine. Occasionally it saves me from a bad day.
Mistake #5: Building for Myself, Not My Workflow
The deepest mistake: I built my prompt library as a storage system instead of a workflow system. I was solving the wrong problem. The real friction wasn't finding prompts — it was the distance between a prompt and the tool I was actually working in.
Even with a well-organized library, my workflow was: think of need → open browser tab → navigate to library → find prompt → copy → switch to AI tool → paste → add context → run. That's seven steps with three context switches. No wonder I defaulted to typing from scratch.
A prompt library that lives outside your workflow is a prompt library that doesn't get used. The storage problem is easy. The integration problem is where most people stop building.
The Framework That Actually Works: TVAR
After all of this, I settled on a four-part structure for every prompt I keep:
T — Trigger: One sentence. Exactly what situation causes me to reach for this. Written as "When I need to..." Not a category, a moment.
V — Variables: Explicit list of what changes each time I use this. [TOPIC], [TONE], [OUTPUT FORMAT]. No hidden assumptions. If the prompt depends on something, it's a variable.
A — Assumptions: What has to be true for this prompt to work well. Model version, context length, type of input. This is where prompt decay shows up first.
R — Result standard: What good output looks like. One or two sentences. When you're in a hurry, you'll skip evaluating the output — this is your quick check.
TVAR takes five minutes to fill out once and saves you from every mistake above: it forces trigger-based thinking, requires abstraction, surfaces assumptions that can decay, and sets a quality bar.
How AI Handler Approaches This
Everything above is hard-won from building and rebuilding my own systems. The consistent problem is that prompt libraries live outside the tools where work actually happens. You build something thoughtful in Notion or Obsidian, and then the moment you're in flow — in a coding assistant, a writing tool, a research workflow — you don't switch contexts to go retrieve it. You improvise.
AI Handler is the tool I'm building to close that gap. It's a unified AI workflow layer that keeps your prompt library inside your actual workflow, not adjacent to it. Prompts with TVAR structure, trigger-based retrieval, decay reminders built in, and direct injection into whatever model or tool you're running. One context, not seven steps.
The goal isn't to build a better Notion for prompts. It's to make the distance between "I know exactly what prompt I need" and "that prompt is now running" as close to zero as possible.
AI Handler is the unified AI workflow tool I am building. Launching June 2026. Email ceo@eternalsix.com for beta access.
Top comments (0)