How to Write Reusable AI Prompts for Claude and GPT-4

6 min readPromptOS
prompt engineeringClaudeGPT-4developer tools

If you have spent any time working with Claude, GPT-4, or other large language models, you have probably noticed a pattern: you write a prompt, it works well, and then two weeks later you need something almost identical — but you have already forgotten exactly how you phrased it. You rewrite it from scratch, tweak it for an hour, and get something that is almost as good. This is the reusable-prompt problem, and it has a straightforward solution.

Why Prompts Should Be Treated Like Code

A well-crafted prompt is an asset. Like a function in your codebase, it encodes specific knowledge about how to get a reliable output from an LLM. When you leave that knowledge inside a chat window, it rots. When you version-control it, parameterize it, and test it, it compounds.

The three practices that make the biggest difference are: using explicit placeholders for variable content, separating the system prompt from the user message, and tracking prompt versions alongside your code.

1. Use Explicit Placeholders

The most common mistake is writing prompts with hard-coded specifics that need to change each time. Instead, extract those specifics into named placeholders.

A common convention is double curly braces, borrowed from template engines like Handlebars and Jinja:

Summarize the following {{content_type}} in {{word_count}} words or fewer.
Focus on {{focus_area}}.

Content:
{{content}}

With this structure, the same prompt template works for a legal contract, a GitHub PR description, or a customer support ticket. You fill in the placeholders at runtime, either manually or programmatically.

Good placeholder naming rules

  • Use snake_case — it is easier to scan than camelCase inside prose.
  • Describe the role of the value, not its type: {{target_audience}} rather than {{string1}}.
  • Mark optional placeholders clearly: {{tone | optional}} or leave a comment in the template file.

2. Separate System Prompts from User Messages

Both Claude and GPT-4 support a multi-turn message structure with distinct roles: system, user, and assistant. Treating these as two separate template slots — rather than smashing everything into one big string — gives you much finer control.

The system prompt: persona and constraints

The system prompt sets the model's role, output format, and non-negotiable constraints. It rarely changes between calls to the same endpoint:

You are a senior technical writer. Your job is to rewrite developer documentation
so that it is clear to a junior engineer with no domain knowledge.

Rules:
- Use plain English. Avoid jargon unless you define it on first use.
- Keep sentences under 25 words.
- Output Markdown. Use headings, bullet lists, and code blocks where appropriate.
- Never invent facts. If you are uncertain, say so.

The user message: the variable part

The user message carries the content that changes on every call. Keep it minimal — just enough context for the model to act:

Rewrite the following documentation section:

{{raw_docs}}

Separating these two slots makes it easy to swap the system prompt independently of the user message and vice versa. It also mirrors how the APIs actually work, so your templates map directly to your API calls with no translation layer.

3. Version Your Prompts

A prompt that worked well in March may behave differently after a model update, or after your product requirements shift. Without versioning, you have no way to reproduce a previous result or understand what changed.

Minimal versioning approach

  1. Store each prompt template as a file in your repository (e.g., prompts/summarize-document/v1.md).
  2. Include a short front-matter block with the model it was tested against, the date, and any known limitations.
  3. Use Git history as your audit log — commit messages should explain why a prompt changed, not just what changed.

A minimal front-matter format that works well in Markdown files:

---
slug: summarize-document
version: 2
model: claude-opus-4-5
tested: 2025-11-01
placeholders: [content_type, word_count, content]
---

If you are building a product, consider storing prompts in a database with a version column so you can run A/B tests across prompt versions without a code deploy.

4. Test Your Prompts Like You Test Code

A prompt is only as good as its outputs across a variety of inputs. Manual testing during development is fine, but you need a repeatable test suite if you plan to iterate on a prompt over time.

What a prompt test looks like

For each prompt template, maintain a small set of input fixtures and the expected output characteristics (not the exact text — LLMs are non-deterministic):

  • Golden inputs: inputs you know should produce correct outputs. Run these after every prompt change and fail the build if outputs regress.
  • Edge cases: empty content, very long content, non-English input, inputs that are off-topic. Verify the model handles them gracefully rather than hallucinating.
  • Adversarial inputs: inputs that try to override the system prompt or inject new instructions. Confirm your system prompt holds.

Evaluation heuristics

Because LLM output is not deterministic, your test assertions need to be heuristic rather than exact. Useful checks include:

  • Output length is within an expected range
  • Required sections or keywords are present
  • Prohibited content (e.g., the placeholder string itself) is absent
  • Output parses correctly as the expected format (JSON, Markdown, etc.)

Tools like pytest with a custom LLM client, or purpose-built evals frameworks, make this practical to automate.

Putting It Together

The pattern for a reusable, maintainable prompt looks like this:

  1. Write a system prompt that describes the model's role, output format, and hard constraints. Store it in version control.
  2. Write a user message template with named {{placeholders}} for variable content.
  3. Add a front-matter block noting the model version, date, and placeholder list.
  4. Build a small test suite of golden inputs and edge cases you run after each change.

This is not glamorous work, but it pays compound interest. Every hour you invest in a well-structured prompt template saves future hours of debugging mystery outputs and rewriting prompts from memory.

PromptOS is built around exactly this workflow — save a prompt, tag it, version it, and share it with your team. If you are tired of losing your best prompts to chat history, give it a try.