System Prompt Testing: Cases, Checks, and Regression Tests

System prompt testing checks whether an assistant follows its standing instructions across a repeatable set of situations. Save the exact prompt, run realistic inputs, and judge each result against written criteria before accepting a change. A convincing answer in one conversation is a starting point, not enough evidence to approve a revision.

Tools like fenbs keep prompt revisions, test outcomes, and lessons with the project so the next assistant can read why an instruction changed. Run the actual tests in your AI app or testing software; keep a useful record of what passed, what failed, and what still needs review.

Where should you start your first review?

1. Choose one job, such as drafting a customer reply from a supplied policy. Write what a useful answer must do and what it must never do.
2. Save the current instructions as a named version. Record the model, available tools, relevant settings, and supplied documents alongside it.
3. Collect ordinary requests and past failures. Replace private details with fictional ones while preserving the difficulty that caused the failure.
4. Write the passing criteria before running the cases. Check the current version first, then a candidate revision under the same conditions.
5. Review the differences, keep the evidence, and have the responsible person accept or reject the revision. Preserve the previous version for recovery.

If the instruction layers are unclear, read system prompt vs. user prompt before testing. For sample instructions to adapt, see system prompt examples; this workflow evaluates an instruction set you already have.

Which cases belong in the test set?

Start with the work the assistant actually handles. Say a small design studio uses it to draft replies about website revisions. A useful set includes a complete request, a missing attachment, conflicting approval notes, and a request to promise a delivery date nobody authorized.

Give every case a stable name. Save the full conversation when a failure depends on earlier messages, rather than testing only its last sentence. Anthropic recommends task-specific evaluations and edge cases↗ (opens in a new tab), including missing information and ambiguous inputs.

Keep reusable instructions separate from test inputs. If a failed case changes the way future work should be checked, save that lesson in fenbs alongside the project, where a connected assistant can read it before similar work.

What should count as a passing answer?

Use observable checks. Replace "sounds professional" with a short scoring guide: states the next action, uses only supplied facts, and makes no unsupported promise. Mark factual requirements separately from preferences about tone so polished writing cannot hide an important failure.

Case: reply-missing-page
Prompt version: client-reply-v3
Input: Please change the headline.
Required: Ask which page the client means.
Forbidden: Invent a page name or claim the edit is complete.
Observed output: [paste the actual answer]
Result: [pass, fail, or needs human review]
Reason: [point to the relevant words]
Reviewer: [responsible person]

A simple check can verify an exact category or required field. A person should review judgments such as whether a reply misrepresents the source. If another AI scores the output, compare some of its ratings with human ratings first and keep disagreements visible.

Google documents rubric-based and computation-based evaluation↗ (opens in a new tab). A rubric is a written scoring guide; a computation-based check uses a fixed calculation or rule. Choose the method that fits the requirement rather than treating every answer as an exact text match.

How do you compare revisions fairly?

Change one thing at a time when diagnosing a failure. Keep the inputs, model, supplied material, and tool setup the same while comparing the current instructions with your proposed edit. Start each independent case in a fresh conversation so earlier answers do not influence the comparison.

Repeat cases when variation would affect your decision. Record the repetitions and their individual outcomes, including failures. If a prompt follows a rule twice and breaks it once, report that variation; do not save only the answer you liked. Matching settings makes comparisons more useful without guaranteeing identical answers.

Reserve some realistic cases that you do not use while editing. These help reveal instructions that work only on your familiar examples. Compare results by requirement: fixing missing-information handling matters, but it should not quietly weaken the restriction on unsupported promises.

Which failures need more than a prompt edit?

Classify the cause before adding another sentence. The assistant might lack the policy document, receive an outdated tool result, or encounter an action the application should prevent. A longer prompt cannot supply missing evidence or enforce a permission in the software that performs an action.

• Unclear instruction: rewrite the conflicting or vague requirement, then rerun the affected cases.
• Missing source: fix how the relevant material reaches the assistant, then test that full path.
• Broken action: check the tool request, its response, and the application behavior separately.
• Unauthorized action: enforce access in the application and verify refusals there, in addition to testing the assistant.

Use the guide to types of software testing to place these checks in a broader release process. Instructions also should not be treated as secret storage; system prompt leaks covers that separate exposure problem.

When should you rerun the old cases?

Rerun them after changing instructions, the model, important source material, or the tools the assistant can use. A regression test repeats an earlier check to catch a returning failure. Keep the original failure case even after it passes; it now protects behavior you already repaired.

A short smoke test can check that the workflow still runs before a larger review. Before accepting a revision, run the complete maintained set and examine important failures individually. Passing your examples supports a decision about those cases; it does not prove the assistant will handle every future request.

Close each review with the accepted version, cases run, unresolved failures, reviewer, and reason for the choice. In fenbs, History records who changed the work, while Lessons learned keeps the practical correction available for the next review.

How to do this with fenbs

1. Create a free account and add a project for the assistant workflow you want to improve.
2. Save the reusable instructions in Skills and prompts. Include a version label in the text so test records can identify the exact revision.
3. Add a task for the review. Put the cases and acceptance checks in its plan; after running them elsewhere, record what was tested, the result, and any limits in the task testing fields.
4. Record the responsible person's choice in Decisions and rules. Add a lesson for a failure that should change future work, and keep the accepted prompt text current.
5. Ask a connected assistant to read the project context before continuing. Save Where we left off with the next check and any decision still waiting on a person.

fenbs keeps the work record; it does not run model evaluations for you. If you only need automated test execution, use testing software for that job. For more ways to maintain reusable instructions, visit the AI prompts hub.