A developer should structure a Claude prompt as a testable contract between application intent and model behavior. Define the task and acceptance evidence, place stable application instructions in the system prompt, put the current request in the user message, separate reference material from untrusted input, choose zero-shot or representative examples deliberately, state constraints and output expectations, and then test the complete template against normal, edge, and adversarial inputs. Revise one suspected component at a time and version the prompt with its model configuration and evidence.

This procedure improves reliability without promising determinism. Clear roles, examples, delimiters, and output instructions make intent easier for Claude to follow, but they do not enforce authorization, prove factual correctness, guarantee a schema, or neutralize prompt injection. Deterministic application controls must validate outputs and govern sensitive actions, while formal evaluation determines whether a prompt is good enough for its intended workload.

Start with the Task Contract

Anthropic's prompt-engineering overview begins from defined success criteria and empirical testing rather than isolated wording tricks. Before writing a template, specify what the application needs the response to accomplish.

A useful task contract contains:

  • Actor and audience: who requests the work and who will consume the result;
  • Task: the transformation, analysis, classification, draft, or decision support required;
  • Allowed inputs: the data the prompt may use and the role of each source;
  • Output expectation: the information, format, and level of detail the consumer needs;
  • Constraints: prohibited behavior, uncertainty handling, and scope limits;
  • Acceptance evidence: examples or tests that distinguish a useful response from an unusable one; and
  • Escalation: conditions that require refusal, clarification, or human review.

Write these as application requirements first. A prompt cannot repair a contradictory task, missing source data, or an output requirement the application has not defined.

Assign Prompt Components to Clear Roles

The Messages API reference separates the request-level system parameter from conversation messages. Use that separation intentionally.

System prompt for stable application guidance

The system prompt is appropriate for stable role, task policy, high-level behavior, and reusable constraints that apply across user requests. Keep it focused on what the application actually needs. Long collections of generic principles compete for attention and are difficult to test.

The system prompt is not an authorization layer. Application code must still decide which user may submit a request, which data may enter, and which downstream action may execute.

User message for the current request

Place the user's current task, request-specific parameters, and approved input content in the user message. Preserve the distinction between the user request and external content being analyzed. A document that says “ignore earlier instructions” is data, not a new system instruction.

When a conversation includes prior turns, include only the authorized history required for the current task. Managing long-running context and durable memory is a separate architecture concern; prompt construction should not silently turn all historical content into permanent policy.

Reference context for evidence

Put source material in a labeled region and tell Claude how it may be used. State whether the answer must rely only on the supplied context, whether missing evidence should be reported, and how references should be represented. Do not describe retrieved or user-provided text as trusted merely because the application inserted it.

Arrange Components in a Deliberate Template

Anthropic's current Claude prompting best practices supports explicit structure, clear instructions, examples, and XML tags where they improve separation. A reusable template can use this order:

  1. stable role and objective;
  2. current task;
  3. reference context and untrusted data boundaries;
  4. constraints and decision rules;
  5. representative examples, when needed;
  6. output expectations; and
  7. a final instruction to perform the task using the supplied material.

The exact placement should follow current guidance and testing for the workload. The durable principle is that every component has a purpose and can be changed independently.

Use explicit delimiters for content boundaries

XML tags or equally explicit labels can separate task instructions, reference data, examples, and output requirements. For example:

<task>
Classify the support request and explain the evidence for the classification.
</task>

<allowed_categories>
billing, account_access, product_question, other
</allowed_categories>

<untrusted_request>
{{customer_supplied_text}}
</untrusted_request>

<output_requirements>
Return one category, a concise explanation, and whether human review is needed.
</output_requirements>

The tag names are application-defined. They make boundaries visible to the model and maintainers, but they do not sanitize the enclosed text or guarantee that the model will ignore instructions inside it. Escape or encode data as required by the destination, validate the complete request construction, and preserve security controls outside the prompt.

Make positive instructions concrete

State what Claude should do, not only what it should avoid. “Do not be verbose” leaves the target unclear; “Give a three-bullet summary followed by one uncertainty statement” is testable. When a constraint depends on domain meaning, define that meaning or supply an example rather than relying on an ambiguous adjective.

Avoid unnecessary threats, emotional pressure, or claims that the model must always be correct. Reliability comes from clearer contracts and evaluation, not from exaggerated prompt language.

Choose Zero-Shot, Single-Shot, or Multi-Shot Prompting

Examples should solve a demonstrated ambiguity. They consume context and can teach unintended patterns, so add them deliberately.

Use zero-shot when instructions are sufficient

Zero-shot prompting provides the task and constraints without a worked example. It is a good starting point when the task is common, the output is simple, and the instruction can define success clearly. Starting without examples also reveals which behavior needs clarification instead of hiding weak instructions behind a single favorable demonstration.

Use single-shot for one critical pattern

One example can establish an unfamiliar format or demonstrate an important boundary. It can also overfit behavior to that one case. Use single-shot prompting when one pattern materially resolves ambiguity, and test whether the model improperly copies incidental names, values, length, or tone.

Use multi-shot for varied decision boundaries

Multiple examples can show diversity, edge cases, and distinctions among categories. Choose examples that are relevant, correct, and representative rather than merely numerous. Keep their structure consistent with the requested output, and include difficult boundaries that matter to the application.

A useful example set varies the feature the model must learn while avoiding irrelevant variation. For a classifier, examples might cover each supported category, an ambiguous case that needs human review, and an out-of-scope case. The application still needs independent tests; examples inside a prompt are instruction material, not an evaluation set.

State Output Expectations Without Confusing Them with Enforcement

Describe the response the consumer needs. Useful output instructions can specify:

  • required sections or fields;
  • allowed labels or categories;
  • desired level of explanation;
  • treatment of missing evidence and uncertainty;
  • whether to quote, summarize, or cite supplied material; and
  • conditions that should trigger clarification or human review.

Plain-language format instructions can improve consistency, but downstream code should not parse prose as though it were guaranteed data. When the application needs machine-readable shape, use current structured-output capabilities and validate through the procedure in Structured Claude Outputs, Validation, and Defensive Parsing.

Prompt wording and schema enforcement solve different problems. A prompt communicates task intent; a schema constrains supported structure; deterministic code validates syntax, semantics, authorization, and downstream use.

Separate Untrusted Input from Instructions

Anthropic's prompt-injection mitigation guidance recommends layered defenses rather than relying on one prompt. Treat user messages, retrieved documents, web content, tool results, and external metadata as untrusted unless another system has established a narrower trust claim.

Prompt-level practices include:

  • placing stable policy outside the untrusted data region;
  • labeling the source and purpose of external content;
  • delimiting untrusted content clearly;
  • instructing Claude to analyze the content rather than follow instructions found inside it;
  • requesting explicit uncertainty or escalation when evidence is insufficient; and
  • avoiding unnecessary inclusion of secrets, credentials, or privileged data.

These practices are defense in depth, not enforcement. The application must still restrict tool access, validate requested actions, apply least privilege, require approvals, isolate execution, and monitor failures. Detailed guardrails and secret management belong to the security architecture.

Apply a Repeatable Prompt-Engineering Procedure

Use this sequence for a new prompt or a material revision.

Step 1: Define success and failure

Write representative acceptance criteria before editing prose. Identify the user outcome, unsafe outcomes, missing-data behavior, and escalation boundary. If the team cannot agree on those, the prompt is not ready to implement.

Step 2: Create trust zones

Classify stable application instructions, user intent, retrieved content, examples, operational metadata, and secrets. Exclude unnecessary data and assign each remaining component to a visible region in the request.

Step 3: Draft the minimum instruction

State the task, context, constraints, and output expectation in direct language. Begin zero-shot unless evidence shows examples are needed. Avoid combining multiple independent objectives into one instruction when the application can sequence them explicitly.

Step 4: Add examples to fix observed ambiguity

Choose single-shot or multi-shot examples based on the failure pattern. Make examples correct and representative, and label input and output consistently. Do not include an example merely because a template expects one.

Step 5: Test across input classes

Run the prompt against normal cases, boundary cases, missing or contradictory data, untrusted instructions embedded in content, and cases that should escalate. Compare responses with the acceptance evidence rather than judging one output by fluency.

Step 6: Diagnose the smallest cause

Identify whether the failure comes from unclear task wording, missing context, conflicting constraints, bad examples, output ambiguity, model compatibility, or application validation. Change one suspected component when practical so the next result provides useful evidence.

Step 7: Version the complete configuration

Record the prompt version, model ID and supported controls, component ordering, example set, input contract, output expectation, verification date, and evidence used to approve the change. A prompt without its model and application context is not a reproducible configuration.

Step 8: Hand off to formal evaluation

Prompt iteration finds and corrects weaknesses; it does not replace a maintained evaluation set, regression criteria, trace analysis, or release gate. Once the template is coherent, validate it through the application's evaluation and testing process.

Worked Example: Evidence-Based Classification

Suppose an application classifies incoming incident descriptions for a human operator. An unreliable first prompt might say: “Read this and classify it.” The task has no category vocabulary, evidence requirement, uncertainty behavior, or trust boundary.

A stronger design would:

  1. define the permitted categories in reviewed application configuration;
  2. state that the result supports a human decision rather than authorizing an action;
  3. put the incident text in an explicit untrusted-data region;
  4. request a category, supporting evidence from the supplied text, and a human-review flag;
  5. include examples only for ambiguous category boundaries;
  6. require an “other” or escalation outcome when evidence is insufficient; and
  7. validate the result and category in application code.

This example improves the contract but does not prove production quality. The team still needs representative evaluation cases, injection tests, authorization controls, and monitoring.

Common Prompt-Engineering Mistakes

  • Starting with clever wording instead of a task contract. Prompt style cannot compensate for undefined success.
  • Mixing policy and untrusted content. Preserve roles and label content origin before serialization.
  • Treating XML tags as a sandbox. Delimiters clarify structure but do not enforce trust or authorization.
  • Adding many examples without a diagnosed need. Examples can consume context and teach incidental patterns.
  • Using examples as the test set. In-prompt demonstrations and independent evaluation evidence have different purposes.
  • Requesting a format without downstream validation. A well-instructed response remains model output.
  • Changing prompt, model, examples, and controls together. Bundled changes obscure causality and rollback.
  • Optimizing for one favorable response. Model behavior is non-deterministic and version-sensitive.
  • Putting all historical context into every request. Context selection and durable memory require their own lifecycle design.
  • Using prompt instructions as security enforcement. Sensitive actions require deterministic controls and approvals.

Relevance to Claude Certified Developer – Foundations

The Claude Certified Developer – Foundations Exam Guide v1.0 includes clear instructions, examples, system and user roles, output constraints, prompt component placement, iteration, and untrusted-input handling within Prompt Engineering. LLM Fundamentals also includes zero-shot, single-shot, and multi-shot prompting.

The durable skill is not memorizing one “best prompt.” It is designing a prompt as a reviewable application asset: every component has a purpose, trust boundary, owner, test, and version context. That method remains useful as model behavior and product controls change.

Conclusion

Reliable prompt engineering is a controlled procedure. Define the task and evidence, assign system and user roles, separate reference and untrusted content, choose examples only when they solve a demonstrated ambiguity, state output expectations, test varied inputs, revise the smallest likely cause, and version the complete configuration.

Prompts improve model guidance; they do not guarantee truth, schema conformance, authorization, or security. Keep deterministic enforcement, context lifecycle, and formal evaluation in their dedicated layers so prompt iteration remains focused, measurable, and maintainable.

Authoritative Sources