Give the brief, not the dump

The problem

Once people learn to name the outcome, the next instinct is to hand over everything. They paste the whole Slack thread, three old docs, the meeting notes, and a paragraph of history, on the theory that more context can only help.

It usually doesn't. The facts that matter end up buried next to ones that don't, and the model has no way to tell them apart. A stale decision from last quarter gets the same weight as today's constraint. A side comment gets treated as a requirement. And when a critical fact is missing, the model doesn't stop. It fills the gap with a plausible guess and builds the whole answer on top of it.

The technique

Treat context like a brief, not an archive. Include a fact only if it would change the answer. Then give the model permission, and an instruction, to ask before it designs anything.

Copy-ready brief:

Outcome: [what you want produced].

Facts that matter: [3–6 items that change the answer].

Current state: [what exists now, what's already decided].

Out of scope: [what to ignore, even if it's in the material].

Before you start: list any missing information that would change your approach. Ask those questions first. Do not invent answers.

A quick filter for each fact: if it were different, would the answer be different? If not, cut it. Background that's nice to know but changes nothing is noise.

What this looks like

Before:

Here's our full product spec, last month's planning notes, and the customer email thread. Write a migration plan for the billing system.

After:

Write a migration plan to move billing from our in-house system to Stripe. Facts that matter: about 4,000 active subscriptions, annual and monthly plans, no downtime allowed during business hours, finance closes the books on the 3rd. Already decided: we keep our own invoice numbering. Out of scope: pricing changes. Before you plan, list anything you'd need to know that I haven't told you.

The second version is shorter and gives the model more to work with. It also usually comes back with two or three sharp questions first, like whether there are proration rules or customers on legacy plans. Those are exactly the facts that would have been guessed at, and gotten wrong, in the first version.

Limits

A tight brief only works if you know which facts matter. When you don't, say so and ask the model to help you find out what to gather before it plans anything. Some tasks really do need a large source, like reviewing a contract. In that case, attach it, but still say what to look for. A clean brief also doesn't confirm the answer is right. Checking the output is a separate step — covered later in this series.

Try it

Take a prompt where you pasted a large block of material. Write down the three to six facts that would actually change the answer, add "ask me what's missing before you start," and run it again. Compare how many follow-up corrections each version needed.