Prompt Engineering Best Practices
Write clearer prompts that give models the role, task, context, constraints, and output format they need.
A prompt is an interface
A prompt is the structured request an application gives to a model. It can include instructions, examples, source material, constraints, and a requested format. Think of it like a brief for a capable but literal collaborator: the model may fill gaps with guesses if the brief is vague. Good prompting does not mean finding a magic phrase. It means making the desired task, available evidence, boundaries, and success criteria easy to distinguish.
State the task precisely
Begin with an action and a clear outcome. “Summarize this report in five bullets for a new manager” gives the model more direction than “tell me about this.” Define the audience, scope, length, tone, and what to do when information is missing. If the task has several stages, name them in order. Precise instructions reduce avoidable variation, but they cannot compensate for absent facts or a model that lacks the needed capability.
const prompt = [
'Task: Summarize the report for a new manager.',
'Context: Use only the supplied report.',
'Constraints: Return exactly five bullet points.',
'If a fact is missing, write "unknown".',
'Report: Revenue increased 12% while support tickets fell 8%.'
].join('\n');
console.log(prompt);Provide useful context
Supply the information the model cannot infer, such as a product definition, policy, target audience, data fields, or examples of acceptable output. Label context as reference material and separate it from instructions. Include relevant edge cases and explain specialized terms. Too little context forces guessing; too much irrelevant context raises cost and can hide the important details. Start with a small, representative context and expand only when testing shows it is needed.
Use examples carefully
Few-shot examples show the model the pattern you want without changing its weights. An example can clarify tone, field order, level of detail, or how to handle an unusual case. Choose examples that are correct, diverse, and close to real inputs. Inconsistent examples teach inconsistent behavior. Never include private customer information merely to make a prompt look realistic; use synthetic or properly approved data and verify that examples do not contain hidden instructions.
Request a useful format
Tell the model exactly how the response should be shaped when another person or program will consume it. You might request headings, a table, a JSON object, or a short answer followed by assumptions. For software, pair the prompt with schema validation rather than trusting formatting instructions alone. Define allowed values and missing-data behavior. A clear format makes outputs easier to read, compare, test, and reject when they fail validation.
Ask for uncertainty
Models often produce fluent answers even when evidence is incomplete. Add instructions such as “use only the supplied sources,” “mark unsupported fields as unknown,” or “state what would need verification.” This encourages useful restraint, though it is not a guarantee of honesty. For higher assurance, check claims against retrieved evidence, use deterministic rules, or require a human reviewer. An uncertainty statement should lead to an action, such as checking a source or escalating a decision.
Iterate with evaluation
Treat prompts like small programs that need tests. Build a set of normal, ambiguous, difficult, multilingual, and adversarial examples. Compare versions for accuracy, completeness, consistency, latency, cost, and safety. Save failures with the prompt and model version so you can reproduce them. A prompt that works in a demonstration may fail on real inputs, so evaluate before release and after changing the model, context, tools, or output schema. Repeat the checks whenever real users reveal a new failure.
Respect the boundary
Prompting can guide a model, but it cannot replace application controls. Keep authentication, authorization, payment rules, privacy decisions, and destructive-action checks in code or trusted services. Treat user content and retrieved documents as untrusted data, even when they look authoritative. Protect secrets, minimize personal information, disclose meaningful automation, and provide a correction path. The best prompt supports a responsible workflow; it does not make the model the final authority at all times.
Worked example: extracting a bug report
A useful prompt can turn an issue description into fields such as reproduction steps, expected behavior, actual behavior, severity, and missing information. It should not decide that a security issue is harmless merely because the text sounds calm. Ask the model to quote the evidence for each field and use “unknown” when the report does not support a value. A validator can reject missing required fields, while a triage engineer makes the final severity decision. This separates language transformation from risk ownership.
Code walkthrough
The example builds a prompt by joining labeled lines, which makes its contract visible and easy to test. In production, keep the template versioned, delimit user-provided content, and pass the result through a schema validator. If the output is JSON, parse it and check required keys, types, enum values, and maximum lengths before storing it. Prompt text can improve the probability of valid output, but only validation can determine whether the returned object is safe for the next program step.
Practical exercise
Create two prompts for the same support-ticket task: one vague and one with a role, allowed evidence, output schema, missing-data rule, and one positive example. Test both against five tickets, including one with contradictory details. Score each result for field accuracy, unsupported claims, and formatting validity. Revise only one instruction at a time and record the change. This gives you a small regression set instead of relying on a memorable single demonstration.
Sources and further reading
These primary or specialist references informed the concepts in this guide. Product details can change, so verify current documentation before implementation.