Interview

Read the plan document and then interview the user about it using the AskUserQuestion tool. The goal is to surface hidden requirements, challenge assumptions, and stress-test the plan before implementation begins.

## Step 1: Find and read the plan

If $ARGUMENTS is provided, treat it as a file path (relative to `docs/` if not absolute) and read that file. If no argument is given, list files in `docs/` and pick the most recently modified `.md` file that looks like a plan (contains phases, tasks, checkboxes, or the word "plan" in the name). If ambiguous, ask the user which plan to use.

Read the entire plan document carefully. Also read any CLAUDE.md files relevant to the areas the plan touches, so you understand the codebase constraints.

## Step 2: Interview the user

Use AskUserQuestion to ask 2-4 questions per round. Keep going until the user says they're done or you've exhausted meaningful questions (typically 3-6 rounds).

### What makes a good interview question

The point of this interview is to catch the things the plan author didn't think about — the gaps between what's written and what will actually happen during implementation. Good questions come from genuinely engaging with the plan's content and reasoning about what could go wrong or what's underspecified.

**Ask about things like:**

- **Unstated assumptions**: "The plan says X, but doesn't mention how Y interacts with it. What happens when...?"
- **Missing error paths**: "Phase 2 adds this new flow, but what should happen if the server returns Z mid-stream?"
- **State management gaps**: "When the user does A then B, where does the intermediate state live? Is it persisted or ephemeral?"
- **UX edge cases the plan glosses over**: "The plan says 'show a modal' — what happens on mobile? What if the user navigates away mid-action?"
- **Ordering dependencies**: "Phase 3 depends on the API from Phase 1 — but what if we need to change the API shape during Phase 2?"
- **Performance implications**: "This approach means N database queries per render. Is that acceptable at scale, or should we batch?"
- **Migration and rollback**: "If this goes wrong halfway through, can we revert? What's the rollback story?"
- **Tradeoffs the plan made implicitly**: "The plan chose approach X over Y — was that deliberate? What would change if we went with Y?"
- **Security and data flow**: "User input flows through A -> B -> C here. Where does validation happen?"
- **Integration seams**: "This touches both the frontend state and the DO. Who owns the source of truth during the transition?"

**What to avoid:**

- Questions the plan already answers clearly (read it properly first)
- Generic questions that apply to any plan ("have you considered testing?")
- Questions about things that are obviously out of scope
- Leading questions that push toward a specific answer
- Yes/no questions — always ask open-ended questions that force the user to think

### Question style

Be direct and specific. Reference exact parts of the plan ("In Phase 2, step 3, you mention..."). Frame questions around concrete scenarios, not abstract concerns. If you notice a potential contradiction or gap, state what you see and ask the user to resolve it rather than asking vaguely "is this right?"

### Structuring rounds

Each round should have a theme or focus area. Don't scatter questions randomly — group related concerns:

- Round 1: Architecture and data flow questions
- Round 2: UX/UI edge cases and user-facing behavior
- Round 3: Error handling, failure modes, and recovery
- Round 4: Implementation order, dependencies, and risks
- Round 5+: Follow-ups from earlier answers, deeper dives into areas where the user's answers revealed new gaps

Adapt the rounds based on what the user reveals — if their answer to a Round 1 question exposes a big architectural concern, dig into that in Round 2 instead of moving on mechanically.

## Step 3: Summarize findings

After the interview concludes, write a brief summary of:
- Key decisions made during the interview
- Gaps or risks that were identified
- Any changes the user wants to make to the plan

Ask the user if they want you to update the plan document with these findings.