deep-elicit

Files (1)

• SKILL.md

SKILL.md (first lines)

<!-- sage-metadata
cost-tier: sonnet
activation: auto
tags: [elicitation, requirements, architecture, discovery]
inputs: [codebase-context-or-nothing]
outputs: [product-brief, personas, constraints]
-->

# Deep Elicit

Guide the human through comprehensive discovery of what they're building and why.
Not a form to fill — a conversation that surfaces the important decisions.

**Core Principle:** The most expensive bugs are requirements bugs. Spending 10 minutes
on elicitation saves days of rework. But spending 60 minutes loses the human's attention.
Be thorough AND efficient.

## When to Use

ARCHITECT mode, before architecture or planning. When:
- Building a new product or system from scratch
- Major platform redesign or migration
- The scope is large enough that getting the design wrong is costly

Do NOT use when:
- BUILD mode (use `quick-elicit` instead — faster, less thorough)
- The human has already written a detailed brief (accept it, validate it)

## Process

### Round 1: Problem Space (3 minutes)

Start with the WHY, not the WHAT. Ask:

1. **"What problem are you solving? Who has this problem?"**
   Get the core pain point and who feels it. "I want to build a task app" is not
   enough — "My team loses track of client deliverables across 5 projects" is better.

2. **"What happens if this problem isn't solved? What are people doing now?"**
   Understand urgency and current alternatives. This grounds the conversation
   in reality — are people using spreadsheets? A competitor? Nothing?

3. **"What does success look like in 3 months?"**
   Concrete, measurable. Not "users love it" but "50 active teams managing
   projects, 80% weekly retention."

Draft and show:
```
PROBLEM BRIEF:
  Problem: [specific pain point]
  Who: [target users — be specific]
  Current alternative: [what they do today]
  Success: [measurable 3-month goal]
```

"Does this capture the real problem? Anything to adjust?"

**Premise challenge (after Problem Brief is confirmed):**

Before moving to Round 2, surface 2-3 implicit premises in the user's
framing. Present as brief observations:

```
Before we scope this — I see a few assumptions worth examining:

1. [Premise]: [one sentence stating the assumption]
   → [one sentence describing why it might be wrong]

2. [Premise]: [one sentence stating the assumption]
   → [one sentence describing why it might be wrong]

3. [Premise]: [one sentence stating the assumption]
   → [one sentence describing why it might be wrong]

Do these hold, or should we adjust our framing?
```

deep-elicit can challenge 2-3 premises (vs. quick-elicit's 1-2) because
the architect workflow operates at higher stakes and the user expects a
more thorough examination.

**What counts as a premise:** The framing of the problem itself, the
assumed solution category, the assumed scope, the assumed user, the
assumed timeline. NOT technical choices — those come in Round 2/3.

**Record the framing decision** in the brief's Vision section and
prepend to `.sage/decisions.md`:

```
### YYYY-MM-DD — Framing: [initiative]
[Chose framing]. Pain: [pain]. Challenged: [premise names].
(deep-elicit Round 1)
```

### Round 2: Scope and Priorities (3 minutes)

Now narrow from problem to solution:

4. **"If you could only ship THREE features for launch, what are they?"**
   Forces ruthless prioritization. Everything else is post-launch.

5. **"What should this explicitly NOT do? What's tempting but out of scope?"**
   Boundaries prevent scope creep. "We won't build a mobile app for v1" is
   a useful constraint.

6. **"Are there constraints I should know? Budget, timeline, team size,
   compliance, existing systems to integrate with?"**
   Non-functional requirements surface here — security, performance, scale,
   accessibility, regulatory.

Draft and show:
```
SCOPE:
  Must have (launch): [3 features]
  Won't have (v1): [explicit exclusions]
  Constraints: [non-functional requirements]
```

### Round 3: Users and Flows (3 minutes)

From xoai/sage, MIT.

More from xoai/sage