| name | interview |
| description | Interview users to turn an issue, rough plan, or implementation idea into spec-ready decisions. Use when the user asks to interview/probe/question a plan, when issue-to-spec needs design clarification, or before writing a spec that depends on product, technical, rollout, or scope decisions. |
| argument-hint | (optional) plan, issue summary, or open questions |
| disable-model-invocation | false |
| allowed-tools | ["Read","AskUserQuestion"] |
Interview
Interview from a solution-design perspective. Use $ARGUMENTS and conversation context as the subject. If the subject is unclear, ask what plan, issue, or decision set to interview.
Principles
- Ask only questions that can materially change the spec, implementation plan, scope, or risk profile.
- Prefer 1-3 related questions per round.
- Probe assumptions, failure modes, edge cases, tradeoffs, and non-goals.
- Do not chase exhaustive certainty; stop when the remaining unknowns can be written as explicit open questions or assumptions.
Flow
- Briefly restate the current goal, known constraints, likely design direction, and highest-risk unknowns.
- Ask the first round with the host's structured question capability when available. If not available, ask concise plain-text questions.
- After each answer, probe only where the response exposes a blocker, contradiction, high-impact tradeoff, or missing acceptance criterion.
- Cover the areas that matter for this subject:
- outcome and success criteria
- affected users and workflows
- design choices and rejected alternatives
- edge cases, error handling, and rollback
- data, API, security, performance, or operational concerns
- dependencies, ordering, rollout, and explicit non-goals
- Finish with a decision summary:
- decisions made
- assumptions accepted
- open questions or deferred risks
- acceptance-criteria seeds
The summary should be directly usable by write-spec, issue-to-spec, or a human author writing the next spec draft.
