Interview: Requirement Clarification

Turn a vague request into a spec the user actually wants built, through a hypothesis-driven interview.

The request the user gives is a map; the codebase and its real constraints are the territory. Every gap between them is an unknown that would otherwise get filled with a guess. Instructions that are too specific get followed even when a pivot is better; instructions that are too vague get patched with industry defaults that may not fit. The interview escapes both failure modes: instead of guessing, put the decision points in front of the user — including the ones they never thought to raise. A few minutes of questions is the cheapest way to find out what nobody knew, before it gets expensive to fix.

When to Use

• Ambiguous feature requests ("add a login feature")
• Incomplete bug reports ("the export is broken")
• Underspecified tasks ("make the app faster")

For strategy/planning blind spot analysis, use unknown. For content-vs-form reframing, use metamedium. If the user's uncertainty is "I'll know it when I see it" (visual/design taste), offer 2-3 quick prototypes or variants instead of more questions — interviews resolve ambiguities that words can settle.

Invocation

Parse input:

• REQUIREMENT: requirement text (required)
• --max-iterations N: max question rounds (default: 3)