Verified against ChatGPT · 2026-08-14
Write a reverse brief that proves you understood a vague request before spending real time on it
Turns a loosely worded request from a manager or client into a reverse brief — restating the goal, assumptions, and success criteria in your own words for their confirmation — so mismatched expectations surface before the work, not after.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are helping me write a reverse brief — restating a request back to whoever gave it to me, in my own words, so they can confirm I've understood it correctly before I spend real time on the work. The goal is to catch a misunderstanding now, not after I deliver something that misses the point. THE ORIGINAL REQUEST, AS GIVEN TO ME "Can you put together something for the board on where we stand with the new product line?" WHO GAVE ME THIS REQUEST AND OUR WORKING RELATIONSHIP My VP, fairly informal Slack-based communication normally. MY OWN GUESS AT WHAT THEY ACTUALLY WANT, IF I HAVE ONE I'm guessing they want a slide or two, not a full written report, focused on revenue traction so far. WHAT WOULD MAKE THIS A WASTED EFFORT IF I GOT IT WRONG If I spend two days on a detailed report but they actually just wanted three bullet points for a five-minute board update. Restate the request in your own words, but do not simply rephrase it more politely — restate it at the level of the actual goal behind the request, not just its literal wording, since a literal restatement can accidentally confirm a misunderstanding just as easily as catch one. Identify every assumption you'd have to make to start the work today, and list each one explicitly as something needing a yes/no confirmation rather than proceeding on a silent guess — if the original request left the format, audience, deadline, or level of polish ambiguous, that ambiguity has to become a visible question, not an assumption baked invisibly into how you restate the brief. State what "done" would concretely look like, specific enough that both of us could look at the finished output together and agree whether it matches — a vague success criterion defeats the purpose of a reverse brief just as much as skipping it entirely. If my own interpretation was provided, check it against the original request and flag any part of it that seems like a stretch or an assumption I'm making rather than something the request actually supports. Explicitly name the specific way this could go wrong that would waste real effort, and turn that into the single most important question to ask before starting. WHAT NOT TO DO Do not write this as a formal document with headers if the relationship is casual — match the tone to the working relationship described. Do not list more than the assumptions that would genuinely change the output if answered differently. OUTPUT FORMAT A short message: restated goal, list of assumptions needing confirmation (each phrased as a direct yes/no question), what "done" looks like, and the single most important clarifying question to ask before starting.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
A reverse brief only works if it restates the request at the level of underlying goal rather than surface wording, because a literal rephrasing of an ambiguous request will faithfully preserve the exact same ambiguity — if the original request never specified format, restating it in slightly different words without addressing that gap gives the requester nothing new to confirm or correct, which defeats the entire purpose; explicitly instructing the model to restate at the goal level forces it to make an interpretive leap the requester can then actually validate or reject. Converting every ambiguity into an explicit yes/no question, rather than folding a best guess silently into the restated brief, matters because a model asked to "clarify a request" will often resolve ambiguity on its own by picking the most plausible interpretation and presenting it as settled fact — which looks efficient but reintroduces exactly the risk a reverse brief is meant to eliminate, since a busy requester skimming a confident-sounding brief is more likely to just say "looks good" without noticing that a real assumption was quietly baked in rather than actually asked. Checking the user's own stated interpretation against the original request, rather than accepting it uncritically, matters because the person asking is often the one most likely to have already anchored on a plausible-but-wrong reading of the request — an assistant that just formats their interpretation nicely without independently checking it against the source adds no real value over what they'd have written themselves. Naming the single most important clarifying question, rather than presenting a flat list of equally-weighted assumptions, does the actual prioritization work a rushed requester needs — a five-item confirmation list often gets skimmed and rubber-stamped, but a message that clearly flags one specific, well-chosen question is far more likely to actually get a considered answer before the work begins.
What you get back
Restated goal: you want something that gives the board a clear read on the new product line's traction so far — sounds like this is about giving them confidence in the direction, not a comprehensive operational report.
Assumptions needing confirmation: - Format: is this 2-3 slides, or a written one-pager? (assuming slides based on 'for the board') - Focus: revenue traction specifically, or also team/roadmap progress?
Done looks like: a board member could glance at it and answer 'is this product line working' in under a minute.
Most important question: is this meant to stand alone, or will you be presenting it live and just need supporting visuals?
Verified against
ChatGPT GPT-5.1 · 2026-08-14
Changelog
- 2026-08-14 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
