lofibrainwav/deep-interview

Deep Interview - Relentless Requirements Discovery

Problem

Users often struggle to articulate complex requirements, jumping between unrelated details or providing vague descriptions that lead to misaligned expectations. This results in wasted time iterating on the wrong solution, misinterpretation of business logic, and frustration for both the user and the system. The current approach of asking a long list of questions at once often causes users to provide shallow, non-committal answers, preventing the system from discovering the true intent behind the request.

Description

This skill conducts a relentless, one-on-one interview to uncover hidden requirements by walking down every branch of the decision tree. Unlike a standard questionnaire, this is a dynamic conversation where the system asks one question at a time.

Upon receiving an answer, the system immediately analyzes it to determine if it opens new branches of inquiry. It recursively digs into these new branches before moving to the next unrelated topic, ensuring the decision tree is fully explored. Crucially, this skill proactively explores the existing codebase before asking a single question. If the answer can be deduced from the code, the system provides it to the user instead of asking, saving valuable time. The interview continues until every assumption is surfaced, every ambiguity is resolved, and a shared understanding is reached.

Application Conditions

Use this skill when the user's task description is ambiguous, vague, or contradictory. It is essential before planning or implementing complex features where multiple valid interpretations exist. Additionally, utilize this skill when the user explicitly requests a "deep dive," "clarification," or wants to stress-test a preliminary plan or design.

• Task description lacks specific details regarding triggers, users, scope, or technical constraints.
• User says "interview," "clarify," "grill me," or "what do I need?"
• Multiple valid interpretations of the requirement exist, or the user wants to verify the feasibility of a proposed plan.
• You need to map out the full decision tree and all edge cases before writing a single line of code.

Summary

The deep-interview skill acts as a consultant, guiding the user through a structured, adaptive discovery process. It combines codebase analysis with targeted questioning to build a complete specification document. By adhering to a strict "one question at a time" rule and automatically resolving questions via code exploration, it ensures the final output is a robust, verified plan with no lingering ambiguities.

Quick Reference

# Full Exploration (up to 30 questions)
/deep-interview "build a notification system"

# Focused Pass (up to 10 questions)
/deep-interview --quick "add caching"

Interview Protocol

Phase 0: Silent Codebase Exploration

Before asking any questions to the user, the system must silently explore the project context.

• Glob: Search for related files (e.g., **/notification/**/*.ts).
• Grep: Search for related patterns (e.g., "alert", "trigger", "subscribe").
• Read: Open and read key files to understand the current state.

Rule: If a question can be answered by exploring the codebase, do not ask the user. The system should provide the answer directly to save the user's time.

Phase 1: Open with Context

Start the interview by establishing a shared baseline:

1. State Knowns: Briefly state what you discovered from the codebase (e.g., "I see you are using Express + PostgreSQL with JWT auth").
2. State Understanding: Summarize your initial interpretation of the task based on the context.
3. Ask One Question: Pose a single, open-ended question to start the conversation.

Example:

"I see the project uses JWT for authentication. You mentioned a notification system. What specifically triggers a notification? Is it for new comments, likes, system announcements, or all of the above?"

Phase 2: The Decision Tree Loop

The core of the interview is a recursive, adaptive conversation.

Core Rules:

1. One Question Per Turn: Never ask multiple questions at once. This prevents cognitive overload.
2. Follow the Branch: When a user answers, analyze the response. Does this answer imply a specific sub-problem? If yes, ask a follow-up question about that sub-problem immediately.
3. Resolve Before Moving On: Do not move to a new topic until the current branch is fully resolved.
4. Explore in Parallel: While waiting for the user's reply, use your "free time" to explore the codebase for information related to the user's answer.
5. State Assumptions: If you are unsure, propose an assumption. "Standard practice is X, does that work for you?"

Decision Tree Logic:

Q1: "What triggers a notification?"
A1: "Comments, likes, follows"
  -> Branch Found: 3 event types

Q2: "Are all three real-time, or are some batched via email?"
A2: "Comments are real-time, the rest are batched email"
  -> Branch Found: Real-time vs Batch

Q3: "For real-time — WebSocket or SSE?"
A3: "WebSocket"
  -> Branch Resolved -> Move to next topic

Q4: "What's the batch interval for emails?"
...

Coverage Areas: Ensure the conversation covers relevant aspects of the system (only what is needed for the specific task):

• Problem: Why is this needed? How is it currently broken?
• Users: Who is affected? What is their skill level?
• Scope: What is In Scope vs. Out of Scope?
• Data: What data flows in/out? Where is it stored?
• Behavior: Happy path? Edge cases?
• Integration: Which existing systems does this touch?
• Performance: Expected load? Latency tolerance?
• Security: Sensitive data? Auth/AuthZ requirements?
• Error Handling: How should failures be communicated?
• Testing: What level of test coverage is expected?
• Deployment: Environment-specific considerations?
• Future: What extensions might be needed later?
• Constraints: Technical limits, timeline, dependencies?
• Validation: How do we determine completion?

Phase 3: Closing

When all branches are resolved (or the question limit is reached):

1. Present Summary: Display confirmed decisions in a structured, readable format.
2. Check for Gaps: Ask "Anything I missed?"
3. Final Confirmation: Ask "Ready to proceed with this?"

Phase 4: Record & Transition

Save the interview results to a persistent location for future reference:

# Interview: {task description}
Date: {ISO date}
Questions Asked: {count}
Mode: full | quick

## Decisions Made
1. {decision}: {rationale}
2. ...

## Scope
- In scope: {list}
- Out of scope: {list}

## Technical Decisions
- {topic}: {choice} (because {reason})

## Data & Integration
- {data flow description}
- {integration points}

## Constraints
- {constraint}: {impact}

## Validation Criteria
- {how to verify completion}

## Assumptions Confirmed
- {assumption}: confirmed by user

After the interview concludes, signal the next step clearly:

══════════════════════════════════════════════════
📋 Interview Complete — {count} questions resolved

[인터뷰 결과가 저장되었습니다: docs/interviews/interview-{slug}-{timestamp}.md]

다음 단계로 계획 문서를 생성하시겠습니까?
  👉 /pdca plan {task description}

인터뷰에서 확인된 결정사항이 Plan 문서에 자동 반영됩니다.
══════════════════════════════════════════════════

Anti-Patterns

Avoid these behaviors to maintain the quality of the interview:

| Don't | Why | Do Instead | |-------|-----|------------| | Ask 5 questions at once | Causes shallow, non-committal answers | One question per turn | | "Is it A, B, or C?" | Forces premature choices | Open question first, then narrow down | | Ask what the code already answers | Wastes user time | Explore codebase first | | Skip a branch to move on | Leaves unresolved assumptions | Resolve every branch fully | | Repeat "What would you like?" | User may not know | Propose an assumption, then confirm | | Always fill 30 questions | Unnecessary friction | End early when branches are resolved |

Interview Style

• Conversational: Sound like a human consultant, not a rigid survey form.
• Contextual Linking: Reference previous answers ("Following up on what you said about X...").
• Assumption-First: "Typically this is done with Y — does that work here?"
• Adaptive Depth: Short answers = dig deeper. Detailed answers = move on faster.
• Progress Indicator: Every 5 questions, state: "We've covered {N} questions so far, currently on {topic}".

When to Use

• Ambiguity: Use when the task description is vague, contradictory, or lacks critical details.
• Complexity: Use before planning or implementing complex features where multiple valid interpretations exist.
• Discovery: Use when the user explicitly wants to "stress-test" a plan or "grill" the system for details.

See Also

• [[pdca]] - For generating the plan document after the interview.
• [[codebase-analysis]] - For understanding how to explore the project structure.
• [[user-story]] - For converting interview results into user stories.
• [[requirements-engineering]] - For broader context on gathering requirements.

• [[patterns]]
• [[context]]
• [[questions]]
• [[reference]]
• [[verify]]
• [[build]]
• [[postgresql]]