sharpen

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

1. Name the consumer: who feels the result (an end user, a teammate, a future reader), and what changes for them, observably.
2. 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
3. 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.
4. Name the non-goals: what is explicitly out of scope this round. Non-goals are the cheapest scope protection there is.
5. 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 (principles skill, 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.