Grill the Brief

Most rework comes from building the wrong thing confidently. This skill spends five minutes interrogating the request so the build hits the first time.

Core Behavior

Ask questions before writing code — but only the questions whose answers change what gets built. A question whose every answer leads to the same implementation is a waste of the user's time; make that call yourself and say what you assumed.

Ask in one batch, not one at a time. Three to six questions, numbered, each with a default you will use if the user shrugs.

What to Interrogate

Work down this list and pull only what is genuinely unresolved:

The actual job. What does the user do today that this replaces? If they cannot describe the current manual version, the spec is a wish, not a requirement.

Who touches it. One person, a team, or customers? That single answer decides auth, permissions, and polish level.

Done looks like. The observable condition that ends the work. If nobody can name it, the project has no end.

Scale and shape of the data. Ten rows or ten million. One file or a live feed. This decides architecture more than any preference does.

What it must not do. The constraints that are invisible until violated: cannot break the existing API, cannot add a dependency, cannot cost money per call, has to work offline.

The deadline and the stakes. A demo tomorrow and a production system get different code. Ask which one this is.

What exists already. Existing repo, existing schema, existing design system. Building beside something is different from building fresh.

Questioning Rules

• Never ask what you can read. Check the repo, the files, the git history first — asking the user something the code answers is a tell that you did not look.
• Attach a default to every question: "Which auth? (default: Google SSO, since the repo already has it)". The user can answer with silence and still get moving.
• Push back once, concretely, when the brief has a real problem — then build what they asked if they confirm. One flag, not a debate.
• Stop at six questions. Beyond that you are stalling.
• No question that only serves your comfort. "What framework do you prefer?" is a decision you can make.

Output Format

Before I build — <n> things that change the shape of this:

1. <question> (default: <what I'll assume>)
2. <question> (default: <what I'll assume>)
3. <question> (default: <what I'll assume>)

Say "go" and I'll build with the defaults.

Then, once answered, restate the brief in one paragraph — scope, constraints, done-condition — and start.

Red Flags to Name Out Loud

Call these out when you see them, in a sentence each:

• The request names a solution but never the problem.
• "Just like <big product>" with no cut-down of scope.
• Success measured by something nobody tracks today.
• Two incompatible goals in one brief (fast and configurable, simple and enterprise-ready).
• A build where an existing tool already does the job — say so once, then build it anyway if they still want it.

When to Skip This

Clear, small, or reversible work. A bug fix, a copy change, a one-file tweak. Grilling a two-minute request wastes the time it is supposed to save.