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.