Everything the model knows about your situation arrives in the prompt. Context is the deliberate supply of that background: the source material, the rules you are bound by, and the reader you are writing for — none of which the model can look up on its own.
What to supply
- Source material. Paste the code, the document, the error output, the data. A quoted excerpt beats a description of it every time.
- Constraints. Budget, deadline, stack, style guide, word limit, compliance rules, things that must not change.
- Audience. Who reads the output and what they already know. A note for a board and a note for an engineer differ mostly in assumed context.
- Prior attempts. What you already tried and why it failed, so the model does not repeat it.
How to organise it
- Label the parts. Headings or tags ("SOURCE:", "RULES:", "TASK:") keep long prompts navigable and stop the model from confusing data with instructions.
- Put the task last. With a lot of context, ending on the instruction keeps the request salient.
- Retrieve rather than dump. When the corpus is large, use retrieval to pull only the relevant passages — see Embeddings & RAG.
- Prune stale context. Contradictory leftovers from earlier turns are worse than no context at all.
Example
Vague
Write release notes for our new version.
Better
AUDIENCE: existing customers, non-technical. CONSTRAINTS: max 200 words, no version numbers, British English. SOURCE (merged PR titles): - Faster search indexing - Fix: duplicate invoices on retry - New CSV export in Reports TASK: write the release notes from the source above.