Interview Me
Run a one-question-at-a-time interview until intent is clear before any spec, plan, or code locks in the wrong build.
Overview
interview-me is a journey-wide agent skill that surfaces what you actually want through sequential questions—usable whenever a solo builder needs to clarify intent before committing to a spec or build.
Install
npx skills add https://github.com/addyosmani/agent-skills --skill interview-meWhat is this skill?
- One question at a time with the agent’s best guess attached for fast correction
- Stops when ~95% confidence you can predict the user’s answers
- Explicitly upstream of idea-refine, spec-driven-development, and doubt-driven-development
- Triggered on vague builds, user says “interview me”, “grill me”, or silent requirement filling
- Targets the gap between stated requests and underlying problems before switch costs appear
- ~95% confidence stop condition
- One question per turn until intent is predictable
Adoption & trust: 1.6k installs on skills.sh; 49.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You asked for a feature-shaped solution without saying who it is for, why now, or what number would mean success.
Who is it for?
Underspecified “build me X” moments, stress-testing fuzzy roadmap ideas, or when you want the agent to stop silently assuming requirements.
Skip if: Frozen, reviewed specs, trivial one-line fixes with explicit acceptance criteria, or when you only need syntax help on existing code.
When should I use this skill?
Ask is underspecified, user says interview me / grill me / are we sure, or agent would otherwise guess requirements pre-plan.
What do I get? / Deliverables
You leave with shared intent the agent can predict, then hand off to idea-refine or spec-driven-development with far less rework risk.
- Aligned intent summary suitable for idea-refine or a formal spec pass
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
User says “build a dashboard”; skill uncovers whether they need ops visibility or investor reporting.
Before a landing page sprint, nail the single conversion event and audience segment.
Before a multi-week refactor, confirm performance target and what must not break.
Clarify what “ready to ship” means for a solo founder launch checklist.
Disambiguate “track everything” into three decisions that actually change behavior.
How it compares
Use before idea-refine or spec skills—conversation to nail intent, not a document generator or post-plan reviewer.
Common Questions / FAQ
Who is interview-me for?
Solo builders and indie founders who notice their agent (or they themselves) are shipping guesses disguised as requirements.
When should I use interview-me?
Use it in Idea when scoping a new product, in Validate before prototyping, in Build before large refactors, in Ship before launch checklists, or anytime you say “interview me” or “are we sure?”
Is interview-me safe to install?
It is conversational only with no special system access; still review the Security Audits panel on this page like any third-party skill.
Workflow Chain
Then invoke: idea refine, spec driven development
SKILL.md
READMESKILL.md - Interview Me
# Interview Me ## Overview What people ask for and what they actually want are different things. They ask for "a dashboard" because that's what one asks for, not because a dashboard solves their problem. They say "make it faster" without a number to hit. The cheapest moment to find this gap is before any plan, spec, or code exists. Once you've started building, switching costs are real, and the user will rationalize the wrong thing into a "good enough" thing. The misfit gets locked in. This skill closes the gap before it costs anything. The other Define-phase skills assume you already know roughly what you want: `idea-refine` generates variations from an idea, `spec-driven-development` writes the requirements down, `doubt-driven-development` stress-tests a plan after you've drafted one. Interview-me is the part before all of those, where you ask one question at a time, with your best guess attached, until you can predict what the user is going to say before they say it. ## When to Use Apply this skill when: - The ask is missing at least one of: **who** the user is, **why** they want it, what **success** looks like, what the binding **constraint** is - The request is conventional rather than specific ("build me X", "make it faster") and you can't unpack the convention without guessing - You're tempted to start with assumptions you haven't surfaced - The user hasn't said which value they're optimizing for when two reasonable ones are in tension (simplicity vs. flexibility, cost vs. speed) - The user explicitly invokes: "interview me", "grill me", "before we start, are we sure?", "stress-test my thinking" **When NOT to use:** - The ask is unambiguous and self-contained ("rename this variable", "fix this typo") - The user has explicitly asked for speed over verification - Pure information requests ("how does X work?", "what does this code do?") - Mechanical operations (renames, formats, file moves) - You already have ≥95% confidence; re-read the stop condition below before assuming you don't ## Loading Constraints This skill needs a live, responsive user. **Do not invoke in non-interactive contexts** like CI pipelines, scheduled runs, `/loop`, or autonomous-loop. If you're in one of those and the ask is underspecified, flag that as a blocker for the user instead of guessing. ## The Process ### Step 1: Hypothesize, with a confidence number Before asking anything, write down your current best read of what the user wants in **one sentence**, plus an honest confidence number (0–100%): ``` HYPOTHESIS: You want a way to answer "how are we doing?" in standup, and "dashboard" was the convention that came to mind. CONFIDENCE: ~30% — missing: who it's for, what "metrics" means in context, and what success looks like ``` The number forces honesty. If you wrote down a high number but can't actually predict the user's reactions to the next three questions you'd ask, the number is wrong. Start at the confidence level you can defend. When confidence is below ~70%, append a brief reason on the same line — what's still unresolved or missing. This tells the user exactly what the interview needs to surface, and prevents the number from being a vague signal. ### Step 2: Ask one question at a time, each with a guess attached Format: ``` Q: <one focused question> GUESS: <your hypothesis for the answer, with the reasoning that produced it> ``` Wait for the user to react before asking the next question. **Why one at