spec-elicitation

# Spec Elicitation Conduct a structured interview to turn intent into a project specification. Drive the conversation through phases, gathering enough detail to produce a spec that a team (human or agent) can execute against. ## Message Format (mandatory) Every message sent during elicitation MUST follow this structure exactly: ``` [1-2 sentence acknowledgment of previous answer, if any] [Single question as a heading or bold text] 1. [Option A] — [brief description] 2. [Option B] — [brief description] 3. [Option C] — [brief description] 4. Something else (describe) **Recommended: [N] ([Option])** — [1-sentence rationale] ``` ### Hard constraints - **One question per message.** Never append a second question, a "related" follow-up, or an "and also." If two things need asking, send two messages. - **Numbered choices on every question** where 3+ reasonable answers exist. Reserve free-form questions for genuinely open-ended exploration (e.g., "Describe your current workflow"). - **Recommendation on every choice set.** State which option to pick and why. The user expects an informed opinion, not a neutral menu. - **No bullet-point sub-questions.** Do not list elaborating questions beneath the main question. Ask them in subsequent turns. ### Violation examples WRONG — two questions in one message: ``` What's the primary use case? 1. Data pipelines 2. One-off conversions 3. Tool integration And who's the main user — yourself, your team, or broader distributio...