The discovery Skill — Requirements Interviews That Propose Before They Ask
How the discovery skill structures requirements gathering as a one-question-at-a-time interview where every question comes with a proposed answer — making the process faster and reducing ambiguity before implementation starts.
Open-ended requirements questions produce incomplete answers. "What are your constraints?" invites a paragraph that covers some constraints but not others, because the person answering does not know which constraints matter most to the implementation. The discovery skill inverts this: every question comes with a proposed answer drawn from available context, and the user confirms, corrects, or expands it.
Core mechanic: propose, then ask
A discovery question has two parts. The question itself names a specific dimension of the requirement — deployment target, testing framework, scale expectation, rollback strategy. The proposed answer makes a concrete guess based on what is already known from the codebase, existing docs, or project memory. The user's job is to say "correct" or to correct it. That takes seconds, not minutes.
The codebase-first rule governs what counts as a question at all. Before asking anything, the skill checks whether the answer already exists in package.json, README.md, CLAUDE.md, or any of the four standard context files (projectbrief.md, productContext.md, techContext.md, systemPatterns.md). If the answer is there, the interview states what it found and asks for confirmation, not a fresh answer.
Three interview modes
The skill selects a mode based on task complexity. Quick Mode covers 5–10 questions and is for L1–L2 tasks: goal, constraints, and done criteria. Standard Mode covers 15–25 questions and adds users and stakeholders, edge cases, dependencies, and alternatives considered. Deep Mode covers 25–50 questions for L3–L4 tasks and extends further into business model, scale projections, security and privacy requirements, external integrations, and migration strategy.
The skill specifies when to stop: the interview ends when all dependency loops are resolved, done criteria are defined, no remaining question would change the implementation approach, or the user explicitly signals readiness. Over-interviewing — continuing when the user confirms every proposal — is called out as an anti-pattern.
Dependency tracking and revisits
Answers can invalidate earlier answers. The skill requires tracking a dependency graph across questions and flagging revisits explicitly. If the answer to question 7 ("do you need real-time updates?") changes the valid options for question 3 ("what database are you using?"), the interview pauses and restates the earlier question with an updated proposed answer. The revisit is marked explicitly so the user knows why the already-answered question is appearing again.
Two additional rules for accuracy
The scope live-grep rule applies when a task touches multiple files of the same kind. Before fixing scope in the PRD, the skill requires a filesystem count of the actual files — ls $HOME/.claude/commands/dr-*.md | wc -l rather than relying on memory. A prior incident caused a PRD to say "15 commands" when the actual count was 17, creating a QA reconciliation cycle.
The source-material re-read rule applies to comparative research tasks. When building a candidate list for technology selection or framework evaluation, every raw material the user provided at task inception must be re-read before finalising the list. Session memory loses candidates that exist only in the source files.
Read what Datarim is for the pipeline context, or the /dr-prd command post for where discovery fits in the requirements phase.