Elicit

Elicit: Tacit Knowledge Extraction

Draw out what the user knows and you can't research. Then check the latest evidence. Then explore options together.

Don't ask a question you could answer yourself. Read the code, search the docs, and check git history first; only ask what's left.

When to Run

1. Explicitly — user invokes /elicit
2. From other skills — any skill can call "run /elicit" before a decision point (e.g. bdd before scenarios, brainstorm when narrowing, debug when symptoms are ambiguous)
3. Proactively — when you're about to make an assumption only the user can confirm

Relationship to other skills

• brainstorm widens the option space (divergent). elicit narrows your uncertainty about user intent (convergent). Use brainstorm when you don't know the options; use elicit when you don't know the user's priorities among options.
• SAFEWORD understanding flow already does contribute-before-asking. elicit is the structured form for decision points where guessing would be costly.

Phase 1: Microquestions

Ask one question at a time. Multiple choice (3-5 options). Force yourself to pre-think the option space so the user reacts rather than generates.

Ask the most discriminating question first — the one whose answer most narrows what you'd do next (highest information gain). Don't walk the categories in order; pick the probe that eliminates the most uncertainty. LLMs default to low-information questions — counter that deliberately. (This is the convergent mirror of debug's disconfirm-first.)

What to ask about

• Intent: Why this way and not another? What was tried and rejected?
• Constraints: What's off-limits? What's coming soon that would change the answer?
• Priorities: When two good options conflict, which value wins?
• Audience: Who reads/uses this? What do they already know?
• Omissions: Is something missing because it's not ready, not wanted, or not thought of yet?

Question format

Good:

This could live in (a) the onboarding flow, (b) the decision-making page, or (c) as a standalone guide. Where would someone look for it?

Bad:

Where do you think this should go?

The good version does the thinking. The bad version makes the user do it.

Guard against anchoring. Pre-supplied options cut effort but also lead — the user may pick from your frame and skip the answer you didn't list. Keep options non-leading and roughly mutually exclusive, and always offer a real escape ("none of these / something else") so the frame itself is rejectable.

How many

Keep asking until one of:

• Answers start repeating or converging
• You have enough to distinguish between options in Phase 3
• User says "enough" or "go"

Usually a handful — fewer for small scope, more for ambiguous scope. Let the stop conditions above end it, not a target count.

Phase 2: Research

After elicitation, check the latest evidence on the decision at hand. Web-search for:

• Meta-analyses or systematic reviews
• Replicated findings with effect sizes
• How leading organizations handle this
• Boundary conditions and known limitations

Skip if the task is purely operational (no empirical claims involved). Defer if the calling skill has its own research phase — don't duplicate work.

Phase 3: Options

Present 2-3 options. Each option:

• What: the approach, concretely
• Why it's good: what it gets right
• What it costs: complexity, length, tradeoff
• Evidence: what supports it (from Phase 2, if applicable)

For small scope (patch/task): just do it — skip the proposal, apply the best option directly. For larger scope (feature/policy): present options, let the user pick.

From Other Skills

When called from another skill, the elicitation results feed directly into the calling skill's next phase. No separate artifact — the conversation is the artifact.