Build a prompt library your team can actually use

Introduction

A good prompt is useful.

A good prompt that your whole team can reuse is much more useful.

Many teams still keep their best prompts inside individual chat histories. Someone finds a good way to ask an AI model to review a pull request. They use it for a few weeks. Someone else writes a slightly different version. The team gets different results from the same tool.

Nothing is versioned. Nobody knows which prompt is current.

This is where prompts start to look less like chat messages and more like engineering assets.

If a prompt affects a business workflow, it deserves some of the same discipline we apply to code.

Put it in source control. Give it a name. Document what it does. Test it with representative examples. Review changes.

This episode is about doing exactly that.

Prompts are part of the system

A modern AI application can contain more than source code. It can contain system instructions, prompts, examples, evaluation data, model configuration, tool definitions and output schemas.

All of these influence behaviour.

Changing a prompt can change the output without changing a line of C# or Python.

Imagine a support assistant. The original prompt says:

Answer the customer's question clearly.

Someone changes it to:

Always apologise and offer a discount.

That is not just wording. It changes business behaviour.

The same is true for an AI code reviewer. Changing a selective instruction into an instruction to report every possible concern can dramatically increase false positives.

The prompt is part of the behaviour. Treat it accordingly.

Start with a prompt repository

The simplest approach is a directory in your repository.

prompts/
├── planning.md
├── code-review.md
├── testing.md
├── debugging.md
├── documentation.md
├── security-review.md
├── incident-summary.md
├── customer-reply.md
├── meeting-summary.md
└── data-extraction.md

You do not need a special prompt-management platform to get started. Git already gives you history, pull requests, reviews, branches and rollback.

Give every prompt a purpose

A prompt should answer one question:

What job is this prompt supposed to do?

Avoid prompts that try to do everything.

A useful prompt file can contain four sections:

Purpose
Instructions
Output
Variables

For example:

# Code Review

## Purpose
Find meaningful problems before human review.

## Instructions
Focus on correctness, security, performance and tests.

## Output
Return severity, category, file, line, message and suggestion.

This is easier for another developer to understand and improve.

Use variables instead of copying prompts

A common next step is copying a prompt and changing the project name. That creates multiple versions of the same thing.

Instead, define variables such as:

LANGUAGE
PROJECT_TYPE
REVIEW_FOCUS

Then one prompt can be reused across projects.

Keep context separate from instructions

The prompt should explain what the model should do. The context should explain what the model is looking at.

Instructions
    +
Project context
    +
User input
    =
Model request

For a code reviewer, the instructions might be fixed while the project context and changed code are supplied at runtime.

This makes the system easier to maintain.

Examples are part of the prompt

One of the most useful improvements is showing the model what a good answer looks like.

Instead of only saying "Be concise", give an example of a useful finding and an example of the kind of vague output you do not want.

You do not need dozens of examples. One or two strong examples can establish the style.

Version your prompts

Treat prompt changes like code changes.

Open a pull request. Explain why the prompt changed. Run it against evaluation examples. Review the results. Then merge it.

Git gives you a history of what changed and why.

If a new version performs badly, you can investigate and roll it back.

Test prompts

You do not need a complicated evaluation platform to start.

Create a few representative inputs.

For a customer support prompt, you might test a delayed order, a refund request, incomplete information and an aggressive customer.

Then define what a good response should contain.

For example:

• No invented policy
• No invented dates
• Clear next action
• Professional tone

Now the question becomes:

Did the new prompt improve behaviour?

That is a much better engineering question than simply asking whether a prompt feels better.

Prompt changes need review

A change from:

Only report high-confidence security issues.

to:

Report possible security issues.

may look small. It could create a large increase in false positives.

The reviewer should ask whether the change will affect developers, customers, cost or operational noise.

That is why important prompt changes belong in pull requests.

Business example: customer support

Imagine a company using AI to draft customer replies.

The first prompt works reasonably well, but the AI sometimes invents policies.

The team adds a rule:

Never invent company policy.
If the supplied information does not contain the answer,
say that the information is unavailable and recommend the
correct next step.

That prompt change is a real business control. Keeping it in source control makes it visible and reviewable.

Business example: internal operations

An operations team might use AI to summarise incidents.

The prompt can require a consistent structure:

• Incident summary
• Customer impact
• Timeline
• Current status
• Actions
• Owners, only when explicitly stated

Consistent prompts create consistent workflows.

The same idea applies to sales summaries, invoice extraction, compliance reviews, engineering documentation and marketing drafts.

Do not create a prompt junk drawer

A prompt library can become messy quickly.

Avoid names like:

review.md
review2.md
review-final.md
review-final-new.md

Use clear names and group prompts by purpose.

The goal is discoverability. A developer should be able to find the right prompt quickly.

Prompt ownership

Important prompts should have an owner.

That does not mean one person writes everything. It means someone is responsible for keeping an important prompt useful.

For example:

Engineering prompts  -> Engineering Platform
Customer prompts     -> Customer Operations
Sales prompts        -> Sales Operations

Ownership becomes especially important when prompts affect customers or regulated workflows.

Prompt security

Do not put secrets in prompt files.

Do not commit API keys.

Do not put customer records into examples.

Use placeholders instead:

Customer name: {{CUSTOMER_NAME}}
Order number: {{ORDER_NUMBER}}

The application supplies the real values at runtime.

Model-specific behaviour

A prompt can behave differently across models.

Keep the core instruction as model-independent as possible, then record important model assumptions separately.

For example:

model: example-model
temperature: 0
structured_output: true

This makes migrations easier because you can run the same prompt and evaluation set against a new model.

Build a small prompt library service

For the companion project, we keep the implementation deliberately simple.

The service:

1. Loads prompt templates from disk.
2. Identifies prompts by name.
3. Substitutes variables.
4. Validates required variables.
5. Returns the rendered prompt.
6. Runs automated tests against the templates.

It does not need a database or an LLM.

That is intentional. The first problem is prompt management. Model execution can sit behind the library later.

A simple API

The example service exposes:

GET /prompts
POST /prompts/{name}/render

A render request might contain:

{
  "LANGUAGE": "C#",
  "PROJECT_TYPE": "Web API",
  "REVIEW_FOCUS": "security and correctness"
}

The service returns the rendered prompt.

This creates a clean boundary between prompt storage and AI execution.

Production advice

Log prompt versions, not sensitive content

It can be useful to know which prompt version was used. You do not necessarily need to log the complete prompt, especially when it contains customer data.

Keep important workflows deterministic

Control the configuration for workflows that need predictable behaviour.

Test important prompts

Keep representative examples and run them whenever a prompt changes.

Review changes

Important prompt changes should use the same change process as important code.

Measure outcomes

Useful metrics can include acceptance rate, correction rate, false positives, false negatives, time saved and user feedback.

Your challenge

Choose one AI workflow you already use.

Move the prompt out of your chat history and into source control.

Then:

1. Give it a clear name.
2. Write down its purpose.
3. Separate instructions from context.
4. Add variables.
5. Add one or two good examples.
6. Create three test cases.
7. Put changes through a pull request.

You have now started treating the prompt as an engineering asset.

Key takeaways

A prompt does not need to be complicated to be valuable.

The important thing is to make it repeatable.

Store it. Name it. Version it. Test it. Review it.

Keep sensitive information out of the repository.

Most importantly, connect the prompt to a real workflow.

The goal is not to build the biggest prompt library. The goal is to build a small set of prompts that people actually use.

What's next?

We have now moved through three levels.

Episode 1 introduced AI-assisted workflows.

Episode 2 used AI to review pull requests.

Episode 3 turned prompts into reusable engineering assets.

The next step is to evaluate the AI itself.

A workflow can look good while producing poor results. The next episode will build a small evaluation set, run prompts against it and compare results.

That moves us from:

I think this prompt is better.

to:

We tested it and the results improved.

That is where AI engineering starts to become measurable.

Repository

The companion project contains prompt templates, metadata, a small .NET prompt library service, variable substitution, validation, xUnit tests, GitHub Actions, Docker support and architecture diagrams.

GitHub: github.com/grbzati1/practical-ai-engineering

Final thoughts

AI is becoming part of software systems.

When that happens, prompts stop being just messages written into a chat window.

They become part of the behaviour of the system.

That deserves engineering discipline.

You do not need a complicated platform.

Start with a folder.

Put the prompts in Git.

Give them names.

Review changes.

Test them.

Improve them.

That small habit can make AI workflows much easier to share, maintain and scale across a team.

And it gives you something even more valuable: a history of what your AI system was told to do.

That is a useful foundation for everything that comes next.