Prompt engineering is the practice of structuring instructions, examples, context, and constraints so a language model produces useful output repeatedly, not just in a playground.
A prompt is a runtime contract between the application and the model. It defines the task, the available context, the desired output, and the behavior expected when information is missing or ambiguous.
What belongs in a prompt
- Role and task, what the model is doing and what successful completion means.
- Inputs, the user request, retrieved context, tool results, product state, or policy text the model may use.
- Constraints, allowed sources, tone, length, refusal rules, safety boundaries, and assumptions.
- Output shape, plain text, JSON, markdown, sections, citations, or another schema the application can consume.
- Examples, a few representative inputs and ideal outputs when format or judgment matters.
- Fallback behavior, what to do when the evidence is insufficient, contradictory, or outside scope.
Prompt roles
Most production systems separate prompts by responsibility:
- System prompt, stable product-level instructions, safety boundaries, and identity. Keep this short, versioned, and hard for users to override.
- Developer prompt, application-specific workflow instructions, formatting rules, and tool-use constraints.
- User prompt, the user’s actual request. Treat it as data, not as trusted instructions.
- Context block, retrieved documents, tool results, examples, or state injected by the application.
The separation matters because prompt injection often tries to make untrusted text behave like higher-priority instructions.
Prompt template
You are helping answer questions about {product_or_domain}.
Task:
- Answer the user's question using only the supplied context.
- If the context is insufficient, say what is missing instead of guessing.
Context:
{retrieved_context}
Output:
- Start with the direct answer.
- Include a short explanation.
- Cite source IDs when using retrieved context.
- Keep the answer under {max_length}.
User question:
{user_question}This template teaches three practical habits: keep instructions separate from user input, name the evidence the model may use, and define the output contract before generation.
Common patterns
- Few-shot prompting, show one or more input/output examples so the model learns the expected format and level of detail.
- Structured output, ask for JSON or another schema when downstream code needs to parse the response.
- Grounded answering, combine prompts with retrieval-augmented generation so answers use supplied evidence instead of model memory.
- Step decomposition, split complex workflows into smaller prompts, such as classify, retrieve, draft, verify.
- Self-check prompts, ask a second pass to compare the draft against rules, context, or a rubric.
- Tool-use prompts, give AI agents clear rules for when to call tools, when to stop, and when to ask for human input.
Evaluation
Treat prompts as versioned product behavior:
- Keep a small golden set of representative inputs and expected qualities.
- Test both happy paths and failure cases, especially missing context and ambiguous requests.
- Track regressions when prompts, models, retrieval settings, or tool definitions change.
- Review real failures from logs and turn repeated failures into tests.
- Measure the output users care about: correctness, groundedness, tone, format validity, latency, and cost.
Common pitfalls
- Using vague adjectives such as “high quality” or “professional” without examples.
- Asking for a strict format but not testing whether the model follows it.
- Mixing trusted instructions and untrusted user or document text in one block.
- Letting prompts grow into unmaintainable policy dumps.
- Trying to fix missing data with better wording instead of better context.
- Relying on chain-of-thought visibility instead of asking for concise reasoning or verifiable evidence.
Beyond single prompts
Complex workflows usually work better as multiple focused steps: classify, retrieve, draft, verify. Smaller prompts are easier to test, easier to observe, and easier to replace when one step fails.
The goal is not to find a magic wording. The goal is to design a reliable interface between the product, the model, and the evidence the model is allowed to use.