Saving Your Best CLI Agent Prompts

A developer spent forty minutes one afternoon crafting the perfect prompt — a detailed instruction that got his agent to generate database migrations exactly the way his team needed them, with the expand/contract pattern, the lock-safety constraints, the down-migration, all of it. It worked beautifully — the kind of result a cli agent prompt library exists to preserve. He used it, moved on, and closed the terminal. Three weeks later he needed it again, couldn't find it, and rebuilt it from memory in five rushed minutes. The rebuilt version was missing the lock-safety constraint. The migration it produced locked a production table. That's the failure hiding in every ad-hoc workflow without a cli agent prompt library: your best prompts are assets, and treating them as disposable throwaways means rebuilding them worse, exactly when you're in a hurry.

Let's tear down the retype-from-memory habit and build a prompt library that treats good prompts like the reusable code they basically are.

Before: The Retype-From-Memory Habit

The weak approach is to write each prompt fresh in the terminal, use it, and let it vanish into scrollback.

[object Object],
claude -p ,[object Object],
,[object Object],
claude -p ,[object Object],

What this does: Shows the same task prompted twice — once carefully, once from fading memory. The second version looks close enough to trust and is missing the exact constraint that prevented a production incident. The knowledge that made the first prompt good evaporated because it was never captured anywhere.

The waste is twofold. You re-spend the effort of crafting a prompt you already perfected. And the rebuilt version is usually worse, because the careful edge cases you worked out the first time are exactly the parts hardest to reconstruct under time pressure.

⚠️ Common mistake: Treating a hard-won prompt as a disposable one-off. The prompts that took real effort to get right — the ones with the specific constraints, the exact output format, the edge cases handled — are precisely the ones worth keeping, because they encode knowledge you won't easily rebuild. Letting them scroll off into terminal history throws away the most valuable thing you produced.

Why It Fails: Prompts Are Assets, Not Keystrokes

The retype habit fails because it misclassifies what a good prompt is. A throwaway question to an agent is a keystroke. But a prompt you refined until it reliably produces correct, constraint-respecting output is an asset — it's captured expertise, the same way a well-tested utility function is. You wouldn't rewrite a working function from memory every time you needed it; you'd import it. Good prompts deserve the same treatment.

There's a compounding cost on teams. When prompts live only in individuals' terminal histories, the whole team keeps independently rediscovering the same prompts, at the same cost, with the same risk of missing a constraint someone else already worked out. A prompt one person perfected should be available to everyone, immediately, instead of re-derived twenty times across the team.

The fix is to treat prompts as durable, versioned, shareable artifacts — a library, not a habit.

After: A Real CLI Agent Prompt Library

The strong approach captures good prompts as reusable, parameterized, shared templates.

First, save the prompt the moment it works, with enough structure to reuse it. Not buried in scrollback — in a named, findable place.

Template: safe-migration
Params: {table}, {change}, {row_count}
Prompt: "Write an expand/contract migration for {table} to {change}. Assume live
traffic and {row_count} rows — no table locks. Include up and down migrations and
a verification query. Backfill separately as a resumable batch."

What this does: Turns the one-off migration prompt into a reusable template with named parameters. The hard-won constraints — expand/contract, no locks, down-migration, separate backfill — are captured permanently, so every future use inherits them instead of depending on memory. The forty minutes of work is banked, not re-spent.

Second, parameterize instead of hardcoding, so one template serves many cases. The migration prompt shouldn't be specific to one table; it should take the table, the change, and the row count as inputs, so it works for every migration you'll ever write.

Third, share the library across the team, so a prompt one person perfects becomes everyone's default. The person who worked out the lock-safety constraint protects the whole team from the incident, once, permanently.

⚡ Pro tip: Save the prompt at the moment it works, not later. The instant an agent produces exactly what you wanted is when the prompt is freshest and you remember why each part is there. Capture it then — five seconds of saving beats forty minutes of rebuilding, and it preserves the reasoning behind the constraints while you still have it.

Breaking Down Each Element

Capture-on-success is the core habit. The moment a prompt produces the right output is the moment to save it, because that's when it's complete and you understand it. Everything else follows from making capture automatic rather than an afterthought.

Parameterization is what makes a saved prompt reusable rather than a frozen one-off. Pulling the specifics out into named inputs turns a prompt for one migration into a template for all of them.

Sharing is the team multiplier. A library everyone can draw from means a good prompt is crafted once and used everywhere, instead of independently rediscovered at full cost by each person.

Versioning is the improvement mechanism. As you refine a template — tightening a constraint, sharpening the output format — the library keeps the current best version, so the whole team's prompts get better together instead of drifting apart.

⚡ Pro tip: Store the why alongside the prompt, not just the text. A one-line note on why the lock-safety constraint is there stops a future teammate — or future you — from "simplifying" it out and reintroducing the exact bug it prevents. The reasoning is as valuable as the prompt, because it's what keeps the prompt from being casually broken.

What Makes a Prompt Worth Saving

A library only works if it's curated — the same lesson from config files applies here. Save every prompt you ever type and the library becomes a junk drawer where the genuinely valuable templates are buried among throwaway questions. Not every prompt is an asset; the skill is knowing which ones are.

Three signals mark a prompt worth keeping. It took real effort to get right — you iterated on it, and that iteration encodes knowledge you won't easily reproduce. It carries specific constraints or an exact output format — the lock-safety rule, the JSON schema, the "change nothing else" boundary — that matter and are easy to forget. And it's something you'll reuse, either because the task recurs or because a teammate faces the same thing. A prompt that hits all three is captured expertise. A one-off "what does this error mean" is not.

Worth saving:  a refined migration template with lock-safety + down-migration baked in
Not worth it:  "explain this stack trace" — a throwaway you'll never reuse verbatim

What this does: Contrasts a high-value template against a disposable prompt so the saving decision is clear. The first encodes hard-won constraints and recurs; the second is a momentary question. Keeping only the first kind is what keeps the library sharp instead of cluttered.

The other half of curation is treating saved prompts as living, testable artifacts. A prompt that worked six months ago against an older model or an older codebase may need updating. Good libraries get revisited, and prompts that no longer earn their place get cut — the same budget discipline that keeps a config file effective.

⚡ Pro tip: When you save a prompt, save an example of the output it produced too. Six months later, the example is how you confirm the prompt still works as intended against a newer model — if the output drifts, the prompt needs a refresh. A saved prompt without a reference output is one you can't easily tell has gone stale.

⚡ Pro tip: Curate on a schedule, not just on save. Every few months, run through your library and cut the prompts you haven't used and can't imagine using. A lean library of prompts you trust beats a sprawling one you have to search through — exactly like the config-file lesson, a smaller set you actually rely on outperforms a complete set you ignore.

Variations for Different Contexts

A backend team keeps a shared library of migration, API-change, and test-generation prompts with the safety constraints baked in, so every engineer's agent produces the team's standard output by default.

A solo developer maintains a personal library of their most-used prompts — the refactor template, the bug-reproduction template, the log-analysis template from this series — parameterized so each works across projects.

A platform team ships prompt templates alongside their tooling, so a new hire inherits the team's accumulated prompt expertise on day one instead of spending months rediscovering it prompt by prompt.

Save and Reuse This

A real cli agent prompt library treats your best prompts as the assets they are: capture them the moment they work, parameterize them so they generalize, share them so the team stops rediscovering the same thing, and version them so they improve together. The retyped-from-memory prompt that locked a production table is what happens without a library — the knowledge you worked out was never saved, so it had to be rebuilt, worse, in a hurry.

This is exactly what PromptABCD is built for — a place to save, parameterize, version, and share the prompts you've perfected, so the forty minutes you spend getting one right pays off every future time you need it instead of scrolling off into terminal history. Start with the prompts from this series, and your next agent task begins from captured expertise rather than a blank line and a fading memory.