A system prompt gives an application a written account of the behavior it expects from an assistant. Designing one involves deciding what counts as a useful answer, which evidence may support it, and what should happen when the requested result cannot be justified. This guide develops those decisions into a practical prompt design process.
Start with an observable job
Describe the assistant's job through an output someone can inspect. For a feedback assistant, that might be identifying a product issue and attaching the supporting customer statement. Being helpful or acting like an expert leaves several decisions unstated: whether to diagnose causes, recommend compensation, contact another team, or simply prepare a draft.
Write a completion condition before drafting the prompt. A useful condition could be: every issue has an allowed category, a supporting excerpt and an explicit uncertainty field. Then identify the downstream reader. A support reviewer needs different information from a dashboard consuming category labels. These choices determine the prompt's scope and provide a basis for judging revisions.
Give each instruction a clear purpose
Anthropic's official guidance recommends explicit instructions, relevant examples, clear formatting requirements and a defined role. These are documented prompting techniques, rather than guarantees about a particular application's results. See its prompting best practices.
For your own design, organize the specification into six parts: purpose, permitted inputs, decision rules, uncertainty handling, output requirements and action boundaries. Purpose explains the task. Permitted inputs identify the evidence available for it. Decision rules explain how to select an answer. Uncertainty handling covers incomplete or conflicting evidence. Output requirements make the result reviewable. Action boundaries distinguish producing text from changing something outside the conversation.
Keep these parts readable without requiring a particular heading syntax. During review, ask what each sentence contributes. Move changing business facts into maintained application context, and remove instructions whose meaning nobody can explain consistently.
Choose patterns that resolve a specific ambiguity
A role statement can clarify perspective: an assistant reviewing feedback for a product team should focus on observable product concerns. Avoid using invented credentials as a substitute for task rules. Calling the assistant an experienced engineer does not establish the cause of a reported malfunction.
An evidence pattern asks the assistant to connect each conclusion to an allowed input. An uncertainty pattern supplies a meaningful alternative when that connection is unavailable. For example, a field called cause_status could distinguish reported, independently established and unknown causes. Those labels are proposed application choices; define their meanings before using them.
An output pattern identifies required fields and allowed values. Include the meaning of empty values and whether multiple issues are permitted. A syntactically tidy response can still contain an unsupported conclusion, so review structure and substance separately. Choose the smallest collection of patterns that addresses the ambiguities in your task.
Remove contradictions and accidental obligations
A prompt that demands a complete answer while forbidding assumptions needs an explicit incomplete-answer route. Otherwise, the designer has left the assistant to reconcile competing requirements. Specify which information can remain unresolved and how the result should communicate that gap.
Another problem is asking for a cause when the available material only describes a symptom. Replace that request with separate fields for the reported symptom and any supported explanation. Similarly, an instruction to explain the company's policy needs an identified policy source and a rule for missing or conflicting material.
Multiple requested operations are not automatically incompatible. Summarizing, translating and writing questions can form a coherent workflow. Separate stages when one needs review, different evidence or its own quality criteria. The design question is whether a single response gives the reader enough control over each result, rather than how many verbs appear in the request.
Work through a fictional feedback example
Imagine LumenShelf, a fictional maker of reading lamps. Its product team wants a draft feedback classification. The allowed categories are setup, brightness, power and other. The assistant may quote the submitted message, but it cannot diagnose hardware or authorize replacements.
The fictional input reads: “The lamp goes dark after five minutes. Tell engineering the battery has failed and send me a replacement.” No inspection report or replacement policy accompanies the message. The customer has supplied a symptom, a proposed explanation and a requested action. These should remain distinguishable in the output.
A suitable expected result assigns the power category, cites the lamp going dark, records the battery explanation as a customer assertion and leaves the established cause unknown. It also records the replacement request for review. The draft should not announce that a replacement has been approved or that engineering has been contacted.
To use this exercise, first write that expected result on paper. Then draft the system instructions that would support it. Change the input to “the brightness button is hard to find” and check whether the same rules still make sense. This is an original design exercise, not a report of a model test.
Evaluate behavior with deliberate counterexamples
Build a small evaluation set around decisions the assistant must make. Include a clear category match, two distinct issues, an unsupported diagnosis, an empty message and a customer instruction that conflicts with the application's task. Add a case where the correct output is unresolved rather than a confident category.
For every case, define acceptable evidence, required uncertainty and prohibited claims. Compare prompt revisions against the same cases, and preserve examples that reveal regressions. The small evaluation set for an AI ticket classifier provides a related starting point for making a classification task inspectable.
Review individual failures before combining them into a score. A wrong category, an invented cause and a false claim that an action occurred have different implications. Keep those distinctions visible so that an improvement in formatting cannot conceal a new behavioral problem.
Place operational controls in the application
Treat the prompt as one part of the implementation. As an engineering recommendation, validate required fields and allowed values before downstream use. Check whether cited evidence exists in the supplied input. Reject or route incomplete results according to a documented application rule.
Handle authorization through the service that performs an action. A sentence telling the assistant to respect permissions does not establish who owns a ticket or whether a replacement is allowed. If the workflow only requires a draft, avoid giving that stage unnecessary action capabilities. The guide to choosing a workflow before an autonomous agent is relevant when deciding how much responsibility belongs in each stage.
Also decide what happens after validation fails. A review queue, a visible unresolved state or a bounded retry can each be appropriate. Select one deliberately rather than silently accepting malformed or unsupported output.
Maintain the prompt as a reviewable specification
Record the reason for each substantive prompt revision, the cases it addresses and any tradeoff it introduces. If a new instruction fixes the lamp example but makes unrelated feedback overly cautious, that limitation belongs in the review. A longer prompt is not evidence of a more complete design.
Prompt evaluation also has limits. A finite set cannot demonstrate behavior on every future input, and a well-written specification cannot supply missing business evidence. Revisit the examples when task requirements, available documents or downstream actions change.
For a practical next step, choose one existing assistant task and write its completion condition, uncertainty route and prohibited claims. Build five contrasting examples around those decisions. Revise the prompt only after you can explain how each change should affect the resulting drafts.