onejaejae/interview

Interview

Extract detailed, actionable specs by reverse-interviewing the user.

When to Use

• User wants requirements extracted through structured questioning
• Vague request needs clarification before implementation
• Complex architecture/refactoring needs systematic scoping
• User says "요구사항 정리해줘", "스펙 작성", "인터뷰"

Do NOT use when:

• User already provides a detailed spec
• Task is simple enough to implement directly (typo fix, single-line change)

Quick Reference

| Phase | Action | Key Rule | |-------|--------|----------| | 1. Context Discovery | Scan codebase + categorize topic | Always scan code BEFORE asking | | 2. Deep Interview | Multi-round AskUserQuestion | 2-3 questions/round, build on answers | | 3. Completion Check | Verify all criteria met | Don't stop early, don't drag on | | 4. Spec Output | Write specs/{topic-slug}.md | Always this path, always structured |

Protocol

Phase 1: Context Discovery

MANDATORY: Scan the codebase FIRST using Read, Glob, Grep.

• Understand current implementation before asking anything
• This prevents asking questions the code already answers
• Ground your questions in the user's actual code

Then categorize the topic:

• New feature → user stories, acceptance criteria, edge cases, constraints
• Refactoring → pain points, target architecture, migration strategy, risk
• Bug analysis → symptoms, reproduction, environment, expected vs actual
• Architecture design → requirements, scalability, trade-offs, integration

Categories are guides, not constraints. Adapt freely.

Phase 2: Deep Interview

Use AskUserQuestion with 2-3 questions per round.

Rules:

• Build on previous answers — go deeper, not sideways
• Avoid questions the codebase already answered
• Provide concrete options, always allow "Other"
• Dig into what the user hasn't considered

Adapt round count:

• Concrete tasks (clear feature + target + scope): 1-2 rounds
• Vague or architectural topics: 4-6 rounds

Cover these dimensions as relevant:

• Technical constraints and implementation details
• UI/UX considerations and user flows
• Edge cases, error scenarios, failure modes
• Trade-offs the user hasn't articulated
• Dependencies and integration points
• Non-functional: performance, security, scalability
• What's explicitly out of scope

Phase 3: Completion Check

End ONLY when ALL are true:

• Core requirements are implementable
• Key trade-offs explicitly decided
• Edge cases and error handling discussed
• User confirms nothing to add ("Is there anything else?" as final round)

Don't stop early — "I feel I understand" is not a completion criterion. Don't drag on — concrete tasks may satisfy all criteria in 1-2 rounds.

Phase 4: Spec Output

Write to specs/{topic-slug}.md. Always this path.

# {Topic Title}

## Summary
One-paragraph overview of what was decided.

## Requirements
- Concrete, actionable items
- Each specific enough to implement

## Technical Decisions
Key decisions with rationale.

## Edge Cases & Constraints
Scenarios and how to handle them.

## Out of Scope
What was explicitly excluded.

## Open Questions
Unresolved items (if any).

Tell the user the file path after writing.

Handling Mid-Interview Pivots

If the user changes topic mid-interview:

1. Save current progress — write partial spec for the original topic
2. Start fresh Phase 1 for the new topic (codebase scan is mandatory again)
3. Don't carry over assumptions from the previous topic

Common Mistakes

| Mistake | Fix | |---------|-----| | Asking questions without scanning code first | Always Read/Glob/Grep the codebase in Phase 1 | | Asking generic/obvious questions | Ground questions in actual codebase context | | Stopping after 2-3 questions under time pressure | Follow completion criteria, not feelings | | Making assumptions instead of asking | If unsure, ask. Assumptions cause rework | | Writing spec to random location | Always specs/{topic-slug}.md | | Asking 5+ rounds for a concrete task | Adapt depth — simple tasks need fewer rounds |

Red Flags — STOP and Reassess

• Starting to code before spec is written
• "I think I understand enough to start"
• Skipping codebase scan because "it's faster"
• Making 3+ assumptions without validating
• User says "빨리" and you skip systematic questioning