Structure

A prompt is a spec

Treat a prompt the way you’d treat a function’s docstring plus its input validation - if the spec is vague, the implementation (the model’s output) will be inconsistent from run to run, not because the model is unreliable but because you didn’t actually constrain the problem.

Four parts, kept separate

A prompt that reliably produces what you want almost always has these four parts, in this order:

1. ROLE / INSTRUCTIONS  - who the model is acting as, and the rules it must follow
2. CONTEXT / DATA        - the material it should work from (retrieved chunks, a document, examples)
3. TASK                  - the specific thing to do right now, stated plainly
4. OUTPUT FORMAT          - exactly what shape the answer should take

Keeping these visually separate (headers, delimiters like """ or ---, or a structured format like XML tags) does two things: it reduces ambiguity about what’s an instruction versus what’s data to read, and it makes the prompt easier for a human to debug later - you can look at section 4 alone to check if a formatting bug is a prompt problem or a parsing problem.

This is the same structure lesson 5 of the RAG track uses for grounding context - it’s a general prompting pattern, not something specific to retrieval.

Position matters

Within a long prompt, models tend to attend more strongly to the start and the end than to content buried in the middle - a real, commonly observed effect, not just folklore. Practical consequence: put your most important constraints in the instructions section near the top, and restate the single most critical one right before the task, especially if a lot of context sits between them.

INSTRUCTIONS: Answer only from the CONTEXT. If it's not there, say so.
CONTEXT: <2000 words of retrieved text>
TASK: Answer the question below.
Reminder: if the answer isn't in the context above, say you don't know - don't guess.
QUESTION: ...

That reminder line is redundant with the top instruction on paper, and earns its keep in practice.

Specific beats vague

Compare:

• “Don’t write too much” vs. “Answer in 2-3 sentences.”
• “Format it nicely” vs. “Return a markdown table with columns: Name, Status, Owner.”
• “Be professional” vs. “Use plain, direct language. No exclamation marks. No emoji.”

Every vague instruction is a coin flip the model has to resolve on its own, differently each time. A specific, checkable constraint removes the coin flip - which is also exactly what makes a prompt testable (lesson 4).