# Elicitation Methods — structured ways to draw out what the user knows

CC's interviewing moments (onboard, seed, `/plan` scoping, checklist-discover, debrief) improvise their questioning. This is the shared shelf of structured elicitation techniques skills can consult when they need to draw something out — surfacing a hidden assumption, pressure-testing a plan, widening the option space. It sits on the same shelf as `skill-output-conventions.md`: a reference skills *cite*, not a phase they run.

Derived from the BMAD-METHOD advanced-elicitation method set (Apache-2.0; see attribution at the end), curated and adapted to CC's constraints. Several entries are classic requirements-elicitation / creative-thinking craft that BMAD also draws on; those are noted.

## How to use this file

A skill at an interview step consults this file to *choose how to ask* — it does not run a menu. Pick the one or two techniques that fit the moment and the gap you're trying to close, then ask. The technique shapes the question; the conversation stays a conversation.

## Fit criteria (why these and not the other 70-odd)

A technique earns a place here only if it meets all four:

1. **Conversational register** — it works as plain dialogue, not a worksheet or a numbered menu (terminal prose constraint).
2. **One question at a time** — it can be run as a sequence of single questions, never a batch. This is a CC hard rule (`CLAUDE.md`): write interview questions one at a time, never batched.
3. **Fits a named CC moment** — onboard, seed, `/plan` scoping, checklist-discover, or debrief.
4. **No persona-roleplay dependency** — it doesn't require the user (or Claude) to adopt and switch between named personas to function.

## The methods

### First-Principles Thinking
*Moments: /plan scoping, onboard.* Strip away how it's done today and rebuild from what the thing actually needs to do. Use when a plan is anchored on an existing implementation and you suspect the real requirement is simpler or different.
- Ask: *"Ignore how this works today — what does it actually need to accomplish, at minimum?"* then, one at a time, *"Which of those are truly required versus inherited from the current approach?"*

### Pre-mortem
*Moments: /plan scoping, checklist-discover.* Assume the work shipped and failed; reason backward to the cause. Surfaces risks and edge cases the optimistic framing hides. (BMAD-named.)
- Ask: *"Imagine this shipped and quietly failed a month later — what's the single most likely reason?"* then *"What would we have needed to know up front to prevent that?"*

### Inversion
*Moments: /plan, checklist-discover.* Ask how to *guarantee* failure, then avoid those things. Often easier to enumerate than success conditions. (BMAD-named.)
- Ask: *"What's the surest way to make this go wrong?"* then *"Which of those are we closest to doing by accident?"*

### Assumption Surfacing
*Moments: /plan scoping (pairs with the plan-completeness `[NEEDS CLARIFICATION]` marker), investigate.* Name the unspoken assumptions a plan rests on so the shaky ones get checked before building. (Classic requirements-elicitation craft.)
- Ask: *"What are we assuming is true here that we haven't actually verified?"* then take them one at a time: *"How would we confirm that one cheaply?"*

### Socratic Questioning
*Moments: any.* Challenge a claim with "why?" and "how do you know?" until it rests on something solid. Use sparingly — it's a scalpel, not a default. (BMAD-named.)
- Ask: *"What makes you confident that's the right call?"* then follow the answer down one level at a time.

### Constraint Removal
*Moments: onboard (vision), seed (member design), /plan (widen options).* Drop a constraint, see what becomes possible, then add it back deliberately. Widens the option space when thinking feels boxed in. (BMAD-named.)
- Ask: *"If [time / scope / the existing schema] weren't a limit, what would you do instead?"* then *"What's the smallest version of that we could actually do?"*

### Stakeholder Lens
*Moments: onboard (who is served), seed (whose perspective the member encodes).* Re-ask the question from one stakeholder's point of view at a time — the user, a future maintainer, the end customer. One lens per question; never a round-table battery. (Adapted from BMAD's Stakeholder Mapping to honor the one-question rule.)
- Ask: *"From the end user's point of view, what would make this a win?"* then, next turn, *"Now from the person who maintains it a year from now — same question."*

### Analogical Reasoning
*Moments: seed (member design), onboard (mental model).* Find the closest parallel in another domain and borrow its lessons. Good for naming a fuzzy concept or designing something with no obvious precedent. (BMAD-named.)
- Ask: *"What existing thing — in or out of software — is this most like?"* then *"What does that parallel get right that we should copy, and where does it break down?"*

### Five Whys
*Moments: investigate, /plan problem-framing, debrief.* Trace a stated problem to its root by asking "why" about each answer in turn. Naturally one-at-a-time. (Classic root-cause craft BMAD draws on.)
- Ask: *"Why is that a problem?"* — and about each answer, *"And why is that?"* — usually three to five levels reaches the root.

### Expand or Contract for Audience
*Moments: checklist-discover, onboard, debrief presentation.* Deliberately widen or narrow the level of detail to fit who the output serves. Use when scope or depth feels mismatched to the audience. (BMAD-named.)
- Ask: *"Who reads this, and do they need more breadth or more depth than we have?"* then adjust one dimension at a time.

## Considered, not kept

- **Red Team vs Blue Team** — a multi-round attack/defend battery; the full technique needs adversarial persona-switching and several exchanges. The useful core (steelman the opposing case) is covered by Socratic Questioning and Inversion as single questions.
- **Six Thinking Hats** — a six-perspective battery requiring sequential persona adoption; fails the no-persona-roleplay and one-question criteria. The Stakeholder Lens covers the salvageable part, one lens at a time.
- **Any numbered-menu / "pick 1-9" selection flows** — BMAD presents methods as an interactive numbered menu; that interaction model fails the terminal-prose constraint. CC skills choose a technique themselves and just ask.

## Attribution

Several methods here are derived from the BMAD-METHOD advanced-elicitation method set (`bmad-code-org/BMAD-METHOD`, Apache License 2.0). Method *names and descriptions* that originate there are marked "(BMAD-named)" above; the adaptations to one-question-at-a-time conversational flow, the CC-moment mapping, and the classic-craft additions are CC's own. BMAD is Apache-2.0 licensed; this derived reference preserves that attribution.