Prompt engineering fundamentals

System prompts vs. user messages

When working with a chat-style LLM API, prompts have two structural layers.

System prompt

The system prompt usually lives in a separate system parameter outside the conversational message list. It provides context, instructions, and guidelines before the model sees the user’s question.

A well-written system prompt improves the model’s ability to follow rules across the conversation.

Your answer should always be a series of critical thinking questions
that further the conversation. Do not actually answer the user question.

User messages

The messages array is the conversational backbone: an alternating sequence of user and assistant turns. The API enforces two rules:

• Messages must alternate between user and assistant roles.
• Messages must start with a user turn.

Each message contains role and content fields. The model generates the next assistant message from the full conversation history.

Where to put role instructions

Role prompting can live in either the system prompt or the user message. If the persona should persist across the session, the system prompt is the natural home. If the role applies to one task, the user message is enough.

What a good prompt looks like

A good prompt is clear, specific, and structured.

Be clear and direct

The model has only the context provided. Show the prompt to a colleague; if the colleague would be confused about the expected output, the model will be too.

Be specific about intent

Small phrasing changes shift behavior. “Who is the best basketball player?” invites a balanced answer. “If you absolutely had to pick one player as the best, who would it be?” asks for a definitive answer.

Separate instructions from data

Use XML tags to separate instructions from input data.

Answer the user's question using only the document below.

<document>
Four score and seven years ago...
</document>

What is the main topic of the document?

Wrapping input in named tags prevents the model from confusing data with instructions.

Give the model space to think

For complex tasks, visible step-by-step reasoning can improve accuracy. Thinking only counts when it is expressed in the interaction; an instruction to reason internally and output only the answer is not a reliable control surface.

Include examples

Examples are one of the strongest controls for behavior. Provide at least one ideal response in <example> tags, and add examples for edge cases when consistency matters.

Give the model an out

To reduce fabrication, explicitly permit uncertainty: “If you are unsure how to respond, say ‘Sorry, I did not understand that.’” Without an escape hatch, the model may produce a plausible answer instead of admitting uncertainty.

Put the question at the bottom

In long prompts, place the immediate task near the end. This keeps the actual request salient after the model has processed the context.

Start broad, then slim down

Use enough prompt elements to make the behavior work, then remove what testing proves unnecessary. Premature minimalism creates fragile prompts.

Write well

The model mirrors the quality and structure of the prompt. Clear writing produces better output than sloppy writing with the same intent.

The main components of a prompt

Complex prompts are built from up to 10 elements.

Recommended default order

Task context -> Tone context -> Task description -> Examples ->
Input data -> Immediate task -> Precognition -> Output formatting

This order is a starting point. Legal, medical, or document-heavy prompts may move examples or input data earlier when that better fits the task.

When to use each component

Not every prompt needs all 10 elements.

Always include

• User role — Required by the API.
• Immediate task — The current question or instruction.

Use when the situation calls for it

Task context fits persistent personas, domain experts, and workflows where the goal needs to be stated before the work begins.

Tone context fits customer-facing, educational, executive, or editorial tasks where the wrong tone undermines the answer.

Task description and rules fit tasks with constraints, compliance requirements, edge cases, or explicit unknown handling.

Examples fit behavior that must be consistent, especially tricky formats, edge cases, tone, and multi-step reasoning patterns.

Input data fits documents, conversation history, code, search results, or any external source material the model must process.

Precognition fits multi-step reasoning, analysis, diagnosis, code review, math, and tasks where jumping straight to the answer produces worse results.

Output formatting fits responses consumed by software or downstream workflows.

Prefilling fits cases where the response shape must be compelled. Prefill with { for JSON, <response> for tagged XML, or a character marker for roleplay.

Takeaways