Ask probing questions about the request before any plan or code, to surface what the user has NOT anticipated, not just confirm what they already said.
How
- One question at a time, in prose. Never a multiple-choice menu, never a batch of five at once.
- Read the answer, then ask the next most valuable question given it.
- Stop as soon as the scope is answerable (roughly: you could write the orchestrator dispatch prompt without guessing). Do not interrogate for its own sake.
Cover, at minimum
- Scope-out: what is explicitly NOT in scope? What might look included but isn't?
- Edge cases: empty / invalid input, network or backend error, two users at once.
- Existing interactions: does this touch behavior already in place (permissions, RLS, cached data, shared views, another resource)?
- Definition of done: what manual check confirms it works? Who validates before merge?
- Reversibility: if it turns out wrong, how hard is it to undo?
If the user answers "I don't know" to a structural question, propose an explicit hypothesis and ask them to confirm rather than silently choosing.
After grilling
Fold the answers into the orchestrator dispatch prompt (scope-out and acceptance become ticket constraints). Then dispatch the harness as usual.
The orchestrator never invokes this skill: it runs headless and cannot hold an interactive back-and-forth. Grilling is a main-thread, pre-dispatch step.