Reliable LLM outputs usually come from a reliable process rather than a single clever instruction. This prompt engineering guide presents a reusable framework for defining the task, supplying context, setting constraints, requesting a structured response, and evaluating results. Use it as a starting point for chat prompts, internal tools, AI workflow automation, and production systems.
Overview
Prompt engineering is the practice of designing and refining instructions so a language model can complete a task consistently. It includes more than choosing the right wording. A useful prompt makes the objective clear, identifies relevant inputs, defines the expected output, and establishes how uncertainty should be handled.
A prompt that works once may still be unsuitable for a team or application. Production use requires repeatability: different users should be able to provide similar inputs and receive responses that meet the same quality bar. This is why prompt engineering best practices should be treated as part of an evaluation workflow, not as a one-time writing exercise.
The framework below separates a prompt into practical components:
- Role and purpose: what the assistant is responsible for.
- Task: the action the model must perform.
- Context: the information needed to complete the task.
- Process guidance: useful rules for handling ambiguity, missing data, or competing requirements.
- Output contract: the format, fields, length, and style of the response.
- Examples and evaluation: representative cases used to test and improve the prompt.
These components apply across models and tools, although the exact syntax and supported features can differ. For agentic systems, prompts should also clarify tool-use boundaries, confirmation requirements, and what the agent must do when a tool fails.
Template structure
The following prompt template is intentionally explicit. Remove sections that do not apply, but keep the separation between instructions and user-provided data. That separation makes prompts easier to review, test, and version.
System role
You are [role]. Your responsibility is to [primary purpose].
Objective
Complete this task: [specific task].
Context
Use the following information:
[context, source text, records, or retrieved documents]
Rules
- Follow [business or technical rule].
- Use only the supplied context when the task requires grounded answers.
- If required information is missing, state what is missing.
- Do not invent facts, values, citations, or completed actions.
- Ask for clarification when [condition].
Procedure
1. Identify the relevant inputs.
2. Apply the stated criteria.
3. Check the result for omissions and contradictions.
4. Return the requested output.
Output format
Return [format: prose, table, JSON, or function arguments].
Required fields: [field names].
Length or style: [constraints].
Quality checks
Before responding, verify that [acceptance criteria].A system prompt can contain stable behavior and rules, while a user message supplies the particular task and inputs. In an API workflow, keep variable data separate from the reusable instruction wherever possible. This reduces accidental instruction mixing and makes it easier to compare prompt versions.
For structured results, define the schema precisely. For example, specify whether a field is a string, number, Boolean, array, or nullable value. If the application needs machine-readable output, use the model or API's structured-output capabilities when available rather than relying only on a sentence such as “return valid JSON.” See Function Calling vs. JSON Prompting for a comparison of common approaches.
How to customize
Start with an observable task
Replace broad goals with an action that can be checked. “Help with customer support” is difficult to evaluate. “Classify each message as billing, technical, account, or other, and provide a confidence label” is more specific. A clear task also makes it easier to build test cases and identify failure patterns.
Define the source of truth
When accuracy depends on internal documents or retrieved records, tell the model how to use them. State whether it may rely on general knowledge, whether it must quote supplied material, and what it should do when the context does not answer the question. This is central to grounded prompting and retrieval-augmented generation. For related guidance, read Best Practices for Grounding AI Responses with Internal Knowledge Bases.
Use constraints that improve decisions
Constraints should prevent predictable errors, not merely make the prompt longer. Useful constraints include a maximum length, an allowed category list, required fields, prohibited actions, and an escalation condition. Avoid contradictory rules. If the prompt says both “be concise” and “include every detail,” specify which requirement has priority.
Decide how uncertainty is handled
Models may produce a confident-sounding answer even when the input is incomplete. Add an explicit fallback such as “return insufficient information and list the missing fields.” For high-impact workflows, a confidence label should not be treated as a guarantee; pair it with deterministic checks, human review, or a second-stage validation step where appropriate. The guide to reliable AI classifiers provides a useful pattern for this kind of design.
Keep examples representative
Few-shot prompting examples are most useful when they demonstrate the edge cases that instructions alone do not explain. Include examples with ambiguous wording, missing fields, long inputs, and inputs that should be rejected. Keep the examples consistent with the required output schema. A contradictory example can teach the model the wrong priority even if the surrounding instructions are correct.
Examples
Example: support-ticket classification
A practical classifier prompt might define four labels, require a short rationale, and prohibit unsupported inferences:
You classify support tickets into exactly one label: billing, technical, account, or other.
Use the ticket text only. If the issue is unclear, choose other and set needs_review to true.
Return JSON with these fields:
{
"label": "billing|technical|account|other",
"needs_review": true,
"reason": "short explanation based on the ticket"
}
Do not include fields outside this schema.This design is stronger than asking the model to “understand the ticket” because the categories, fallback behavior, and output contract are explicit. Test it with clear examples as well as messages that mention more than one issue.
Example: document summarization
For summarization, specify the audience and what must be preserved:
Summarize the supplied project update for an engineering manager.
Include decisions, blockers, owners, deadlines, and unresolved questions.
Do not add recommendations or facts that are absent from the source.
Use five bullets or fewer. If a required item is not stated, write "Not specified."This prompt can be adapted for meeting notes, incident reports, or requirements documents by changing the audience and required details. A text summarizer should not be judged only on brevity; check whether important decisions and risks remain visible.
Example: tool-using agent
An AI agent needs operational rules in addition to a conversational role. State which tools it may call, when it must ask for confirmation, and what it should report after a call. For example: “Use the order lookup tool for read-only status questions. Before canceling or changing an order, show the proposed action and request confirmation. If the tool returns an error, do not claim the action completed.” For broader architecture considerations, see How to Build an AI Agent with RAG and Tool Use.
Evaluate before optimizing
Build a small evaluation set before making repeated prompt changes. Include normal cases, boundary cases, adversarial wording, and incomplete inputs. Score the dimensions that matter for the task: factual grounding, schema validity, classification accuracy, completeness, refusal behavior, latency, or cost. Change one major prompt element at a time when possible, and record the result. Prompt optimization without a stable test set can improve one example while quietly damaging another.
When to update
Revisit a prompt whenever its inputs, outputs, model, tools, or business rules change. An update is especially appropriate when evaluation cases reveal a recurring error, a new document type enters the workflow, a field is added to an output schema, or users begin phrasing requests differently.
Do not update only the wording. Record the prompt version, the reason for the change, representative test results, and any known tradeoffs. Keep a rollback path for production workflows. Prompt versioning and change tracking can prevent a well-intentioned edit from becoming an undocumented behavior change; see Prompt Versioning and Change Tracking for Production Teams.
To apply this framework today, choose one recurring task and write its acceptance criteria first. Separate stable instructions from variable input, add an explicit fallback for missing information, define the output schema, and test at least one ordinary case and three failure cases. Review the results with the people who use the output, then keep the prompt, test cases, and evaluation notes together. That small cycle turns LLM prompting from trial and error into a maintainable engineering practice.
