Sharpen
A vague brief fails quietly. Sharpening names what the work is for so the first attempt lands near the target — without pinning details the work itself should decide.
Workflow
- Name the consumer: who feels the result (an end user, a teammate, a future reader), and what changes for them, observably.
- Run the expert lens — the goal is a deeper task, not a bigger one.
Before rewriting the brief, answer four questions and fold the answers
in:
- what a top professional in this field would do here that the brief does not ask for
- the rawest material they would start from, instead of what has already been digested for the session
- the specific methods and tools they would use
- what, other than the session or the user, would show the result is right — always keep one such outside check
- Name the done-check: the cheapest observable that says the task is done — a command that passes, a page that renders, a question that answers.
- Name the non-goals: what is explicitly out of scope this round. Non-goals are the cheapest scope protection there is.
- One question, if a real fork remains: if two different tasks both
satisfy the brief and the choice changes the work materially, ask —
one question, with the options and what each would cost. Otherwise
proceed and report the interpretation you took (
principlesskill, Never block on the human).
The deliverable is the rewritten brief, deeper not bigger, with choices that are the user's left open instead of decided.
Rules
- Sharpen the aim, not the solution: how to build it stays open unless the user pinned it.
- Overspecifying is its own failure — a sharpened brief a stranger could execute without chat context, in three sentences or fewer.
- If the brief cannot be sharpened (no consumer nameable, no done-check
findable), say so and route to
deep-interview.