VanaAPI

← Writing

Notes from a prompt folder after a busy month

Daily workEN2026-10-26

A prompt folder usually gets messy in small increments. A useful draft is copied for one project, a quick fix lands in a second file, and soon nobody knows which version is safe to reuse. Tidying the library does not require a new system. It does require a few deliberate habits.

§ Step 1: Choose one home

Put reusable prompts in a shared location that the people who maintain them can edit. Keep experiments separate from prompts used in applications or team workflows. A simple structure is enough:

  • Active: prompts currently used or approved for reuse.
  • Drafts: work in progress and experiments.
  • Retired: prompts kept for reference but no longer recommended.

The names of these folders matter less than the boundary between active work and exploration. If a prompt is copied into a product, record where it is used so a later change does not leave a hidden duplicate behind.

§ Step 2: Give each prompt a useful name

Name prompts for the job they do, not the date they were written or the model they happened to be tested with. “Summarize support handoff” is easier to find than “new prompt final 3.” If multiple prompts handle the same task, add a meaningful distinction, such as “short handoff” or “handoff with open questions.”

Put operating details near the prompt: its owner, intended audience, input assumptions, expected output, and last review date. These notes help a future editor decide whether a change is safe. They also make it easier to spot a prompt that has outlived the workflow it describes.

§ Step 3: Separate instructions from changing data

Keep stable instructions in the prompt and pass changing facts as input. For example, a support response prompt can specify tone, boundaries, and the response format, while the customer’s message and account details arrive separately. This makes the prompt easier to reuse and reduces the risk of stale examples or private information becoming part of a shared template.

Mark placeholders clearly, using a consistent style such as {{customer_message}}. Add a short note describing each required field. Before reuse, check that the calling code supplies every field and handles missing or unexpected input.

§ Step 4: Keep a small test set

Save a handful of representative inputs alongside each important prompt, including an ordinary case and at least one awkward or incomplete case. Record what a good output should do, rather than relying only on a single exact sample. When you edit the prompt, rerun the same cases and compare the results.

If the prompt is used with different models, test the models your workflow actually supports. A result that looks fine in one setting may need adjustment in another. Vana API provides one OpenAI-compatible endpoint and also supports Anthropic Messages and Gemini native protocols, which can be useful when a team wants to keep its prompt workflow while routing to different model families. For instance, a team might check a summarization prompt with Claude Sonnet 5.5 and Gemini 3.1 Pro. Treat those runs as checks, not as proof that every model will behave identically.

§ Step 5: Review changes as code

Make edits in small, readable steps. Keep a short change note explaining what changed and why, and ask another person to review prompts that affect customers, decisions, or important internal processes. Avoid overwriting a working prompt before its replacement has passed the agreed test cases.

Set a light review rhythm, such as checking active prompts once a quarter or after a workflow changes. The point is not to schedule needless revisions. It is to notice outdated constraints, unexplained copies, and prompts with no clear owner.

§ Step 6: Retire without losing context

When a prompt is no longer used, move it out of the active area and mark it retired. Keep a brief reason and, if known, the replacement. Delete duplicates only after checking whether any application or teammate still depends on them.

A tidy prompt library is not a collection of perfect instructions. It is a place where people can find the current version, understand its limits, and change it without guessing. If you are setting up a workflow that needs access to multiple model protocols through one API, you can create a Vana API account and try it with the prompts you already maintain.