Keep a Prompt Library in Plain-Text Files You Own

The most durable place to keep your best prompts is a folder of plain-text Markdown files: one prompt per file, a few lines of frontmatter for the model and tags, and version control for history. Not a chat history you cannot search. Not a vendor's database. Files you own, reusable across every AI tool.

The prompt that worked perfectly last Tuesday is now buried four hundred messages deep in a thread you cannot search. You half-remember the wording. You rebuild it from scratch, worse than before. This is the normal state of most people's prompt practice, and the research confirms it: in a 2025 study of practitioners, only 11% reuse prompts regularly, while 46% never do ¹. The cause is structural, not personal. A prompt typed into a chat box has nowhere to live.

Why prompts disappear

Prompts vanish because chat is a stream, not a store. You type a prompt, get an answer, and the prompt scrolls away with the conversation. There is no name, no folder, no search that finds it later. The single best wording you ever wrote becomes unrecoverable the moment the thread grows long enough.

The researchers behind the 11%/46% finding name the mechanism plainly: "The lack of modular structures renders it difficult to apply prompts across tasks, reinforcing a tendency to start from scratch with each new query." ² A prompt with no boundary, no handle, no file of its own cannot be reused — so it is not. The fix is to give each prompt the modular structure the chat box denies it: a file.

This is not a fringe idea. When researchers analyzed how prompts are actually stored in public code, they found a clear winner. In an empirical study of 24,800 open-source prompts from 92 GitHub repositories ³, "Markdown is the most widely adopted file format, used by 72.8% (67 out of 92) of analyzed repositories" ⁴. The people who manage prompts most deliberately already keep them as Markdown files. You can do the same with no infrastructure at all.

The single move: one prompt, one file

The whole system reduces to one decision: treat each good prompt as a document, and give it its own file. A prompts/ folder. One Markdown file per prompt. A short frontmatter header naming the model, the tags, and the date. That is the substrate. Everything else — reuse, search, history, portability — follows from it with no extra work.

Naming each prompt as a file is what turns it from disposable input into a kept artifact. The argument that prompts deserve this treatment comes from peer-reviewed software-engineering research. A team at Carnegie Mellon argues "that some prompts are programs and that the development of prompts is a distinct phenomenon in programming known as 'prompt programming'" ⁵.

If a prompt is a kind of program, you store it the way you store programs: in named files, under version control. The convention practitioners reach for is exactly that — a course on prompt engineering instructs readers to "create a dedicated directory within your repository, perhaps named prompts/ or prompt_templates/, to store these files." ⁶

The diagram below is the entire workflow at a glance. Read it top to bottom; the prose under each section spells out every step.

flowchart TD
  A[Prompt that worked] --> B[Save as<br/>one .md file]
  B --> C[Add frontmatter:<br/>model, tags, date]
  C --> D[Commit to git]
  D --> E{Need it again?}
  E -->|Yes| F[grep the folder]
  E -->|Improved it?| G[Edit & re-commit]
  F --> A
  G --> D

Figure: The prompt-library loop. A prompt that worked is saved as one Markdown file, given a short frontmatter header, and committed to version control. When you need it again you grep the folder to find it; when you improve it you edit the file and commit again, building a complete history of every change. Nothing leaves your device.

The five-minute version

You can have a working prompt library in five minutes. The whole setup is a folder, one file, and one commit. Start small — capture the five prompts you actually reuse, not every prompt you have ever typed. A library of five files you trust beats a database of five hundred you never open.

1. Make the folder. mkdir prompts inside any project or notes directory you already keep.
2. Save one prompt. Copy a prompt that worked into prompts/code-review.md. The filename is the handle you will search by later, so name it for the job, not the date.
3. Add a header. Put three or four lines of frontmatter at the top — the model it was written for, a tag or two, the date. Thirty seconds.
4. Write down why it works. One sentence under the prompt: what this version fixed, or when to reach for it. Future-you will not remember.
5. Commit it. git init if the folder is new, then git add prompts && git commit -m "add code-review prompt". History starts now.

Here is a complete, copy-pasteable file. The frontmatter is the metadata layer; the body is the prompt; the notes section is the part most people skip and later wish they had not.

---
title: Strict code review
model: any frontier chat model
tags: [code, review, engineering]
created: 2026-06-17
updated: 2026-06-17
version: 3
---

# Strict code review

You are a senior engineer doing a focused code review. Review the
code I paste next for correctness, edge cases, and readability —
in that order of priority.

Rules:
- Quote the exact line before each comment.
- Separate "must fix" (bugs, security) from "consider" (style, naming).
- If you are unsure whether something is a bug, say so explicitly
  rather than guessing.
- End with a one-line verdict: ship, ship-with-fixes, or do-not-ship.

Do not rewrite the whole file. Point to the smallest change that fixes
each issue.

## Notes

- v3 added the "quote the exact line" rule — without it, comments
  floated free of the code and were hard to act on.
- The "say so explicitly" rule cut confident-but-wrong bug reports.
- Reach for this on pull requests, not on greenfield drafts.

That file is yours. It opens in any editor, on any device, with no account and no app required to read it.

The thirty-minute version

The thirty-minute version is the same folder, grown into a small system: a flat prompts/ directory, consistent frontmatter, a one-line index, and git doing the remembering. You are not building a platform. You are applying three habits — naming, tagging, committing — to a folder you check into version control alongside everything else.

Keep the folder flat until it hurts. A single prompts/ directory with descriptive filenames (code-review.md, meeting-summary.md, blog-outline.md) is searchable long before nested folders help. Researchers studying real repositories warn that even where Markdown dominates, "we observe notable inconsistencies regarding file organization" ⁷ — the format is solved, the organization is not. Start flat, add structure only when a category clearly earns its own subfolder.

Make frontmatter your tags. The YAML header at the top of each file carries the model, the tags, and the dates. This is the same metadata move that turns a folder of notes into a queryable set — covered in depth in the companion piece on YAML frontmatter as a metadata header. For prompts, the highest-value field is tags, because it is what you will filter on when the library grows.

Let git be the history. Every time you improve a prompt, commit it. The payoff is concrete: with version control "you gain a complete history of every change made to a prompt. You can see who changed what, when" ⁸. You can diff version three against version one to see exactly which sentence fixed the output, and you can roll back when an "improvement" made things worse. The mechanics of diffing and rolling back notes you own are the same as for any other file — see version history for notes you own.

Grep to find. The retrieval system is one command. grep -ril "code review" prompts/ finds every file mentioning the phrase; grep -l "tags:.*engineering" prompts/*.md finds everything tagged for engineering. No index to maintain, no search box to load. The folder is the index.

What plain files give you — and what they do not

Plain files give you four things a chat history cannot: ownership, portability, version history, and search. The prompt is a file on your device, readable in any editor, movable to any AI tool, diffable across versions, and findable with one grep. That is the complete value proposition, and it is honest to say it is also the limit.

Plain files do not give you automated evaluation, A/B scoring, latency telemetry, or team access controls. Those belong to a different tier of tooling. Hosted prompt-management registries — Langfuse, PromptLayer, Braintrust — exist precisely to add evaluation, scoring, and telemetry for production teams running prompts at scale, with many engineers and many requests per second. That is a real category solving a real problem.

For an individual reusing a handful of prompts, the file folder is the durable substrate; for a production pipeline, the registry is a genuine tool. The two are not competitors so much as two ends of a spectrum, and most people are at the personal end.

Practitioners are already treating prompts as files in folders at scale. Simon Willison's files-to-prompt utility — which concatenates a directory of files into a single prompt — has over 2,700 stars on GitHub, and one widely shared repository of extracted system prompts has tens of thousands ⁹. The behavior is established. What has been missing is a stated convention for the individual, which is what this post supplies.

The academic call is the same, aimed one level up: researchers argue that "communities and industry stakeholders should establish clear guidelines and standardized formats designed specifically for prompt management using code repositories." ¹⁰ You do not have to wait for the standard. A flat folder of Markdown files is one you can adopt today.

Common mistakes

A prompt library fails for a few predictable reasons, all of them avoidable with one small habit each. The most common are hoarding instead of curating, skipping the note on why a version works, nesting folders too early, editing without committing, and locking the whole library inside one vendor's box. Each trade buys a searchable, reusable library later.

• Hoarding every prompt instead of curating the good ones. A library is the five to twenty prompts you genuinely reuse, not a dump of everything you ever typed. Curate ruthlessly; an untrusted library goes unused.
• No notes on why a version works. A prompt without its reasoning is a magic incantation. Write the one sentence — what this version fixed — or the next edit will undo it.
• Nesting folders too early. Deep directory trees feel organized and search worse than a flat folder with good filenames. Add a subfolder only when one category clearly demands it.
• Editing in place without committing. If you improve a prompt and do not commit, you have lost the diff that tells you what changed. The commit is the whole point of keeping it in version control.
• Locking the library inside one vendor's box. The moment your prompts live only in a tool's proprietary store, you have traded portability for convenience. Plain files travel; vendor databases do not.

How this fits with the notes you already own

A prompt library is not a new kind of tool. It is the plain-text ownership thesis applied to the AI era: your prompts are notes you own, kept where you keep everything else, in a folder that travels with the rest of your work. The durable artifact is a file you hold, not a record inside someone else's service.

If a single persona prompt deserves its own file — the case made in the AI advisory board as a Markdown file — then your whole prompt library does too. Prompts are the input side of working with AI; the conversation and context you keep are the other side, explored in AI agent memory in plain text and why vector databases are the wrong abstraction.

The principle holds throughout. In MNMNOTE, a prompt library is exactly this — plain Markdown files stored locally on your own device, the same as any other note, working offline and readable for as long as you keep them.

Frequently asked questions

How do I manage my prompts in ChatGPT?

Do not manage them inside ChatGPT — keep them outside it. Save each prompt that works as a Markdown file in a prompts/ folder on your own device, with frontmatter for the model and tags. Paste from the file into any chat tool when you need it. The file survives the chat; the chat does not.

Should prompts be in plain text files?

Yes, and the practice backs it up: in a study of 24,800 open-source prompts, Markdown was the dominant format, used by 72.8% of the analyzed repositories ⁴. Plain text is readable in any editor, diffable in version control, greppable from the command line, and portable across every AI tool — none of which a proprietary store guarantees.

How do I organize and version my prompts?

One prompt per Markdown file in a flat prompts/ folder; frontmatter (model, tags, created, updated, version) at the top; git for history. Commit every time you improve a prompt so you keep a complete record of every change and can roll back a bad edit. Keep the folder flat until a category clearly earns a subfolder.

How do I reuse the same prompt across different AI tools?

Keep the prompt as a plain-text file rather than inside any one tool. Because the file is tool-agnostic Markdown, you copy from it into ChatGPT, Claude, a local model, or an API call without rewriting anything. The portability comes from the prompt living outside every vendor, not inside one.

Do I need a prompt-management platform like Langfuse or PromptLayer?

Only if you run prompts in production at team scale and need evaluation, A/B scoring, telemetry, or access controls — that is what those registries add. For an individual reusing a handful of prompts, a folder of Markdown files in git gives you ownership, portability, history, and search with no account and no service to depend on.

Where should I keep my best prompts so I do not lose them?

In a prompts/ folder among the notes you already own, on your own device, under version control. Prompts get lost because chat is a stream with no store; a named file in a folder you back up is a store. As Obsidian's Steph Ango puts it, "Apps are ephemeral, but your files have a chance to last." ¹¹

How many prompts should a library have?

As many as you genuinely reuse, usually between five and twenty. The value is in curation, not volume — a small set you trust gets opened; a large dump does not. The failure mode is non-reuse, not under-collection: 46% of practitioners never reuse prompts at all ¹. Keep the ones that earn their place and delete the rest.

Your best prompts are some of your most valuable writing — keep them where you keep your other writing, in plain files you control, not in a box you rent.

This builds on the plain-text ownership work of Steph Ango's File over app and on Simon Willison's files-as-prompts tooling — and you can keep the whole library, like the rest of your notes, on your own device at mnmnote.com.