When a request is vague, assumption-laden, or "obvious," ask the few load-bearing questions that expose hidden requirements before building or committing.
SkillScore64Maintained
On-demandOn-demand: invoked explicitly — never occupies your agent's context until called.
◆Research pack
Last verified 8/14/2026
What it changes
Passed 14 of 22 test cases with the skill, and 7 of 22 without it.
Without skill32%
With skill64%
Checks it passed that the model alone missed
The response sets resolved_by to self.
The response sets resolved_by to self, user, or mixed.
The response sets resolved_by strictly to self, user, or mixed.
and 4 more in the full report
8 fixed6 passed either way7 still failing1 broke
Pass-rate lift
+32 pp
Tokens
+18%
Agent turns
0%
Response time
-26%
Model gemini-3.6-flashMeasured 8/14/2026v114 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 8
Prompt
An automated test failed with `TypeError: Cannot read property 'map' of undefined` in `src/utils/formatters.js`. We can inspect the local repository files directly. Evaluate this issue using schema fields gap, resolved_by, questions_asked, assumptions_made_explicit, clarified_requirement, next_action, and stop_reason.
What was checked, without and with the skill
Checked
Without skill
With skill
The response sets resolved_by to self.
Missed
Passed
The response sets stop_reason matching clear_enough, self_resolved, or blocked_on_<fact>.
Missed
Passed
case-20 · gemini-3.6-flash · 8/14/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md52 linessingle file
Socratic Questioning
Core rule: Surface the load-bearing assumption or undefined term before you build. Ask only what you cannot resolve yourself; stop when the next action is decision-ready.
When to Use
Request is underspecified ("make it fast", "add a dashboard", "fix the bug") and a guess would misbuild.
Claim rests on an unstated assumption that may be the real problem.
Someone treats a premise as "obvious" or jumps to a solution before the problem is defined.
Debugging a vague symptom that needs a checkable specific before investigation.
When NOT to Use
Spec is already clear and actionable — do the work; do not interrogate for theater.
Ambiguity is resolvable by reading code, running a command, or checking docs — resolve it yourself.
Mid-execution of an agreed plan — re-questioning every step is friction, not rigor.
Emergency where one load-bearing fact is enough to act — clarify that fact, then act (prefer ooda).
You need the strongest opposing case, not clarification — use steel-manning.
You need causal chain depth on a defined failure — use five-whys-plus or scientific-method.
Procedure
Name the gap. State what is undefined, assumed, or uncheckable. If you can fill it from tools/repo without the user, do that and stop.
Ask the load-bearing question first. Prefer one question whose answer most changes what you will build. Categories (use only what the gap needs):
Clarification — "What does X mean / for whom / success looks like?"
Assumption — "What must be true? What if it is false?"
Evidence — "What supports this? What would disprove it?"
Perspective — "Who is affected / who would disagree?"
Implication — "What follows if we do this?"
Meta — "Is this the right question?"
Resolve or branch. From the answer, either (a) write the clarified requirement/decision and proceed, or (b) ask at most one follow-up that still gates the work. Do not run all six categories by default.
Make assumptions explicit. Restate: "This assumes X; success means Y; out of scope is Z." Confirm only if still ambiguous after your restatement.
Stop at decision-ready clarity. When the next action no longer depends on a hidden premise, end questioning and act or hand off. Cap user-facing questions tightly; prefer batching the few that truly gate work.
Output
gap: <what was vague or assumed>
resolved_by: self | user | mixed
questions_asked:
When a real test is too rare, large, or irreversible, run a controlled counterfactual: isolate one variable, fix conditions, trace the mechanistic chain, and bound what the result implies.