Context, constraints & giving good source material
Why pasting the real document beats describing it, how much context is too much, and the constraints worth naming every time.
Paste the thing. A summary of your source material is a lossy copy you made for a reader who never asked for one.
Paste the source, don't describe it
The most common self-inflicted wound in daily prompting is describing a document instead of including it. “I have an email from a client who seems annoyed about the timeline” forces the model to work from your interpretation. Paste the email and it works from the evidence.
This matters most exactly when you are least sure. If you already knew precisely what the client meant, you would not need help drafting the reply. Your summary bakes in the reading you are unsure about.
Long context is cheap now. A model reading 4,000 words of real material will outperform one reading your 40-word gloss of it, nearly every time.
Below is the full email thread. Read it, then answer three questions: 1. What is the client actually asking for, in one sentence? 2. What are they worried about that they have not said outright? 3. What is the smallest reply that addresses both? Thread: --- [paste the entire thread, including your own earlier replies] ---
The constraints worth naming every time
Most disappointing outputs come from unstated constraints — things so obvious to you that you forgot they were not on the page. Five are worth checking before you send anything that matters.
Audience: who reads this and what do they already know? Length: a number, not an adjective. Tone: name a register, or better, point at an example. Scope: what is explicitly out of bounds. Purpose: what should happen after someone reads it — a decision, an approval, a laugh.
Purpose is the one people skip and the one that changes the answer most. “Summarize this meeting” and “summarize this meeting so my manager can approve the budget without reading it” produce different documents from identical source material.
Summarize these meeting notes.
Summarize these meeting notes for my manager, who was not there and has two minutes. She needs to approve a $12k spend. Lead with what we are asking for and the number. Then three bullets of justification. Cut everything that does not help her decide. Notes below:
Same input, different artifact. The second summary is built around a decision; the first is built around the notes.
Too much context is a real failure mode
Padding is not free. If you dump six documents and only one is relevant, the model has to guess which one you meant, and it will sometimes guess by recency or length rather than relevance.
The fix is labels, not deletion. Say what each block is and how to treat it: “the spec is authoritative, the Slack thread is background, ignore anything in the old draft that contradicts the spec.” Ranking your sources is a constraint like any other.
You have three inputs. Treat them with different weight: SOURCE OF TRUTH — the current spec: [paste] BACKGROUND — a Slack discussion, may contain outdated ideas: [paste] STYLE REFERENCE — a doc I like the tone of, ignore its content: [paste] Task: write the implementation summary. Where the Slack thread contradicts the spec, the spec wins and you should flag the contradiction at the end.
Let it ask you first
For anything long or high-stakes, the cheapest improvement is to invert the order: make the model interview you before it writes. You will discover constraints you did not know you had.
This costs one extra exchange and routinely saves three rounds of “no, not like that.”
I need to write [thing]. Before you draft anything, ask me the five questions whose answers would most change what you write. Ask them all at once, numbered. Do not draft until I answer.