interview

Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one.

Use the AskUserQuestionTool to ask about literally anything: technical implementation, UI & UX, concerns, tradeoffs, etc. — but make sure the questions are not obvious.

If a question can be answered by exploring the codebase, explore the codebase instead.

Mandatory interview topics

Beyond the feature's core mechanics, you MUST explicitly probe these areas:

• Entry points: Where does the user navigate FROM to reach this feature? What existing page/nav/button needs to change?
• User journey start-to-finish: Walk through the complete flow from "user is on an existing page" → "user discovers feature" → "user completes the feature" → "user returns to where they were"
• Roles: Which user roles interact with this feature? Check references/project.md for the project's role list; otherwise infer from the codebase.
• Edge cases: What happens on error, concurrent access, mobile vs desktop?
• State transitions across roles: For each state change, which roles see it and how (real-time — SSE/websockets, polling, manual refresh)? What does each role's screen show before and after?
• Terminal states & dead ends: For every end-state, what's the forward action? What URL params, cookies, or tokens does the entry point URL need?

Cross-cutting invariants (MANDATORY): Check references/project.md for the project's invariants document. If one exists, read it and for each invariant ask the "Spec-time question" section during the interview. Every invariant covers a bug class the team has shipped before. The spec must capture the decision for each one — do not leave them implicit.

Output format

Be very in-depth and continue interviewing me continually until it's complete, then write the spec to the file.

The spec MUST end with a structured ## User Stories section. Derive these from the interview — every agreed-upon behavior becomes a story:

## User Stories

- **US-1**: As a [role], I [action] so that [outcome].
- **US-2**: As a [role], I [action] so that [outcome].
...

Rules for user stories:

• Every user role that interacts with the feature must have at least one story
• Navigation/entry point stories come FIRST (e.g. "As a manager, I see a game button on my dashboard so that I can start a ranking game")
• Cover the happy path, key error states, and edge cases
• Stories must be specific enough to verify — "I can use the feature" is too vague
• Number them (US-1, US-2, ...) so the plan can reference them

Project Customization

Read references/project.md in this skill's directory if it exists. It provides project-specific context:

• User roles and their permissions
• Path to a cross-cutting invariants document (if any)
• Real-time transport preference (SSE, websockets, polling)
• Any other project-specific patterns