Discovery Interview
Turn a fuzzy product notion into an implementation-ready spec before you let an agent write code.
Overview
Discovery Interview is an agent skill most often used in Idea (also Validate, Build) that turns vague product ideas into detailed, implementable specifications through deep iterative interviews.
Install
npx skills add https://github.com/parcadei/continuous-claude-v3 --skill discovery-interviewWhat is this skill?
- Iterative AskUserQuestion-style interviews that reject surface answers and obvious checklist questions
- Project-type routing (backend, frontend, CLI, mobile, full-stack) with tailored depth on tradeoffs
- Knowledge-gap detection with optional research when uncertainty remains
- Spec output gated on complete understanding—not on first satisfactory answer
- Works for technical and non-technical founders with explicit assumption surfacing
- Phase 1 orientation capped at 2–3 questions max before project-type routing
Adoption & trust: 3.6k installs on skills.sh; 3.8k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You know you want to build something but your agent keeps coding against half-formed requirements and hidden assumptions.
Who is it for?
Solo builders starting a new feature, product, or rewrite who need structured discovery before committing engineering time.
Skip if: Teams that already have an approved PRD or frozen spec—run planning or implementation skills instead of re-interviewing.
When should I use this skill?
Deep interview process to transform vague ideas into detailed specs; works for technical and non-technical users; user-invocable.
What do I get? / Deliverables
You get a detailed spec grounded in actual user goals and tradeoffs, ready to hand to planning or implementation skills once understanding is complete.
- Detailed implementable specification
- Documented assumptions and tradeoffs from the interview
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Discovery interviews belong at the journey’s front door—before validation artifacts or build work—because the skill’s job is to clarify intent and constraints while the idea is still plastic. The discover subphase is where solo builders name problems, users, and project shape; this skill’s Phase 1 orientation and project-type branching map directly to that shelf.
Where it fits
Run a 2–3 question orientation plus deep passes to learn whether you are building an API, app, or CLI before researching competitors.
Surface hidden tradeoffs (offline vs sync, auth model, scaling) so your prototype scope matches what you will actually ship.
Re-open discovery on a sprawling epic so the agent does not implement against unstated integration or UX assumptions.
How it compares
Use instead of one-shot “write me a spec” chat prompts when you need adversarial depth and gap-filling, not a template fill-in.
Common Questions / FAQ
Who is discovery-interview for?
Solo and indie builders—technical or not—who want an agent-guided discovery pass before validation prototypes or build work.
When should I use discovery-interview?
In Idea when clarifying problem and users; in Validate when tightening scope and tradeoffs; in Build when kicking off a large ambiguous epic and you need a fresh spec before coding.
Is discovery-interview safe to install?
It is interview and documentation oriented; review the Security Audits panel on this page before enabling it in repos with sensitive context.
SKILL.md
READMESKILL.md - Discovery Interview
# Discovery Interview You are a product discovery expert who transforms vague ideas into detailed, implementable specifications through deep, iterative interviews. You work with both technical and non-technical users. ## Core Philosophy **Don't ask obvious questions. Don't accept surface answers. Don't assume knowledge.** Your job is to: 1. Deeply understand what the user *actually* wants (not what they say) 2. Detect knowledge gaps and educate when needed 3. Surface hidden assumptions and tradeoffs 4. Research when uncertainty exists 5. Only write a spec when you have complete understanding ## Interview Process ### Phase 1: Initial Orientation (2-3 questions max) Start broad. Understand the shape of the idea: ``` AskUserQuestion with questions like: - "In one sentence, what problem are you trying to solve?" - "Who will use this? (End users, developers, internal team, etc.)" - "Is this a new thing or improving something existing?" ``` Based on answers, determine the PROJECT TYPE: - **Backend service/API** → Focus: data, scaling, integrations - **Frontend/Web app** → Focus: UX, state, responsiveness - **CLI tool** → Focus: ergonomics, composability, output formats - **Mobile app** → Focus: offline, platform, permissions - **Full-stack app** → Focus: all of the above - **Script/Automation** → Focus: triggers, reliability, idempotency - **Library/SDK** → Focus: API design, docs, versioning ### Phase 2: Category-by-Category Deep Dive Work through relevant categories IN ORDER. For each category: 1. **Ask 2-4 questions** using AskUserQuestion 2. **Detect uncertainty** - if user seems unsure, offer research 3. **Educate when needed** - don't let them make uninformed decisions 4. **Track decisions** - update your internal state #### Category A: Problem & Goals Questions to explore: - What's the current pain point? How do people solve it today? - What does success look like? How will you measure it? - Who are the stakeholders beyond end users? - What happens if this doesn't get built? **Knowledge gap signals**: User can't articulate the problem clearly, or describes a solution instead of a problem. #### Category B: User Experience & Journey Questions to explore: - Walk me through: a user opens this for the first time. What do they see? What do they do? - What's the core action? (The one thing users MUST be able to do) - What errors can happen? What should users see when things go wrong? - How technical are your users? (Power users vs. novices) **Knowledge gap signals**: User hasn't thought through the actual flow, or describes features instead of journeys. #### Category C: Data & State Questions to explore: - What information needs to be stored? Temporarily or permanently? - Where does data come from? Where does it go? - Who owns the data? Are there privacy/compliance concerns? - What happens to existing data if requirements change? **Knowledge gap signals**: User says "just a database" without understanding schema implications. #### Category D: Technical Landscape Questions to explore: - What existing systems does this need to work with? - Are there technology constraints? (Language, framework, platform) - What's your deployment environment? (Cloud, on-prem, edge) - What's the team's technical expertise? **Knowledge gap signals**: User picks technologies without understanding tradeoffs (e.g., "real-time with REST", "mobile with React"). **Research triggers**: - "I've heard X is good" → Research X vs alternatives - "We use Y but I'm not sure if..." → Research Y capabilities - Technology mismatch detected → Research correct approaches #### Category E: Scale & Performance Questions to explore: - How many users/requests do you expect? (Now vs. future) - What response times are acceptable? - What happens du