Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Clarify what the user actually wants before specs, plans, or code. Use when an ask is underspecified, when the user says "interview me", "grill me", "stress-test my thinking", or when you would otherwise fill in important product/architecture assumptions silently.
.claude/skills/kdlbs-interview-me/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-01 | ✗→✓ | ▲ Improved | 15% | 0% |
| case-02 | ✗→✓ | ▲ Improved | -19% | 0% |
| case-09 | ✗→✓ | ▲ Improved | 72% | 0% |
| case-10 | ✗→✓ | ▲ Improved | -28% | 0% |
| case-12 | ✗→✓ | ▲ Improved | 305% | 0% |
Use this before /spec-driven-development, /spec, or /plan when the requested outcome is not clear enough to implement without guessing.
Use when the ask is missing one or more of:
Skip for mechanical edits, obvious bug fixes, pure information requests, or when the user explicitly asks for speed over clarification.
Write one sentence plus a confidence number.
textHYPOTHESIS: You want workspace switching to preserve task context because agents lose momentum when users navigate between workspaces. CONFIDENCE: 45% - missing: who feels the pain, what "preserve" means, and what counts as done.
Format every question with a guess.
textQ: Is this primarily for human users switching between workspaces, or for office agents operating across workspaces? GUESS: Human users, because the pain sounds navigation-related rather than automation-related.
If the active harness provides a native user-question UI that supports multiple questions in one turn, ask 2-4 focused questions together. Keep each question short, include your guess in the prompt or options, and make the options concrete enough that the user can answer quickly.
If no multi-question tool is available, ask one question at a time in chat. Do not send a long questionnaire.
If the user says "modern", "scalable", "best practice", "dashboard", "robust", or "clean architecture" without concrete outcomes, ask:
textIf you did not have to justify this as best practice, what would you actually want?
When confidence is high, restate in this shape:
textHere's what I think you want: - Outcome: - User: - Why now: - Success: - Constraint: - Out of scope: Yes / no / refine?
Do not proceed to /spec, /plan, or implementation until the user explicitly confirms or corrects the restate.
The deliverable is a confirmed statement of intent. If the user wants it persisted, save it only after confirmation, usually in a feature spec via /spec; avoid creating standalone intent docs unless explicitly requested.
Other measured skills in the registry, with their headline benchmark lift.