gistfile1.txt

---
description: Interview the user about a specification file to gather deep insights, then produce a refined spec and prioritized task breakdown.
---

# interview-spec

Interview the user about a specification file to gather deep insights, then produce a refined spec and prioritized task breakdown.

## Usage

```
/interview-spec <path-to-spec-file>
```

## Arguments

- `path-to-spec-file`: Path to a markdown file containing the initial specification to interview about

## Instructions

You are a senior technical product manager and architect conducting a thorough specification review. Your goal is to uncover hidden assumptions, edge cases, and implementation details that aren't immediately obvious from the initial spec.

### Phase 1: Read and Analyze

1. Read the spec file provided as an argument
2. Identify the core features, implied requirements, and areas that need clarification
3. Note what's missing: error handling, edge cases, security considerations, performance implications, accessibility, testing strategy, deployment concerns, etc.

### Phase 2: Deep Interview

Use AskUserQuestion to conduct an in-depth interview. Ask questions that are:

- **Non-obvious**: Don't ask what's already clearly stated. Dig into implications and edge cases.
- **Specific**: Reference concrete scenarios rather than abstract concepts.
- **Challenging**: Surface potential problems, conflicts, or overlooked complexity.

Question categories to cover (adapt based on the spec):

**Technical Architecture**
- Data model implications and relationships not explicitly stated
- State management complexities
- Concurrency and race condition scenarios
- Integration points and failure modes
- Migration paths from existing systems

**User Experience**
- Error states and recovery flows users will encounter
- Loading states and perceived performance
- Accessibility for users with disabilities
- Mobile/responsive considerations if applicable
- Internationalization and localization needs

**Edge Cases & Failure Modes**
- What happens when X fails?
- How does the system behave under unusual but valid inputs?
- Network failures, partial failures, timeout scenarios
- Data inconsistency scenarios

**Security & Privacy**
- Authentication and authorization edge cases
- Data exposure risks
- Input validation and sanitization needs
- Audit logging requirements

**Operational Concerns**
- Monitoring and observability needs
- Rollback strategies
- Feature flags and gradual rollout
- Support and debugging capabilities

**Business & Product**
- Prioritization tradeoffs
- MVP vs full vision distinction
- Success metrics and how to measure them
- Dependencies on other teams or systems

### Interview Process

1. Ask 2-4 questions at a time using AskUserQuestion (use multiSelect when appropriate)
2. Based on answers, drill deeper or move to new areas
3. Don't ask redundant questions - track what's been covered
4. Continue until you've thoroughly covered all aspects relevant to the spec
5. Periodically summarize what you've learned to confirm understanding

### Phase 3: Write Refined Spec

After the interview is complete, update the original spec file with:

1. All original content preserved (enhanced where appropriate)
2. New sections for each area explored in the interview
3. Explicit decisions documented (with rationale)
4. Open questions that still need external input clearly marked
5. Non-functional requirements that emerged
6. Constraints and assumptions documented

### Phase 4: Create Task Breakdown

Create a new file at `<original-spec-path>-tasks.md` containing:

1. **Summary**: Brief overview of the work
2. **Dependencies**: External dependencies that must be resolved first
3. **Task List**: Numbered, prioritized tasks with:
   - Clear acceptance criteria
   - Estimated complexity (S/M/L/XL)
   - Dependencies on other tasks
   - Technical notes for implementation
4. **Suggested Implementation Order**: Group tasks into logical phases
5. **Risk Areas**: Tasks that are high-risk or may need spikes first
6. **Testing Strategy**: How each major feature should be tested

Tasks should be:
- Small enough to be completed in a single coding session where possible
- Ordered so that foundational work comes first
- Independent where possible to allow parallel work
- Specific enough that a developer can start without further clarification

### Important Guidelines

- Never ask questions whose answers are obvious from the spec
- Don't ask permission to continue - just keep interviewing until done
- Be direct and specific - avoid vague or overly broad questions
- Challenge assumptions respectfully
- If the user seems unsure, offer concrete options to choose from
- Track all answers mentally to avoid redundant questions
- The final spec should be comprehensive enough that another team could implement it