quick-elicit

Files (1)

• SKILL.md

SKILL.md (first lines)

<!-- sage-metadata
cost-tier: sonnet
activation: auto
tags: [elicitation, specification, planning, requirements, framing]
inputs: [codebase]
outputs: [spec]
requires: []
-->

# Quick Elicit

Guide the human to articulate a high-quality specification through 4 focused
rounds of questions. Takes ~3 minutes, not 20.

**Core Principle:** The quality of output is determined by the quality of input.
The most expensive failure is building the wrong thing correctly. Round 0
challenges the framing BEFORE the other rounds capture requirements.

## When to Use

BUILD mode, before planning. When the human describes something they want to build,
add, or change — and no specification exists yet.

Do NOT use when:
- A spec already exists in `.sage/work/` (skip to planning)
- The human has provided a detailed written spec (accept it, don't re-elicit)
- FIX mode (the bug report IS the spec)
- The human says "just do it" (respect their autonomy, note the risk)

## Process

### Pre-Elicit: Infer What You Can

Before asking anything, scan the relevant codebase area to understand:
- What tech stack is in use?
- What patterns exist in the codebase?
- What does the area being changed look like?
- What conventions are established?

If a `codebase-scan` has been run previously, use its output. Otherwise,
scan the relevant files directly (read project config, entry points,
and the area being changed).

Also scan `.sage/docs/` for existing research artifacts (jtbd-*, ux-audit-*,
opportunity-*, user-interview-*). If research exists, note the known pain
for use in Round 0.

This determines WHAT TO ASK. Don't ask about things you can already see.

### Round 0: Framing (30 seconds)

**PURPOSE:** Challenge whether the request is framed around the right
problem BEFORE committing to a specification direction.

Ask ONE question:

**"What goes wrong today without this?"**

This is not "what does this feature do?" It's "what specific frustration,
failure, or friction makes this worth building?" The answer should be a
concrete struggling moment, not an abstract category.

- Good answer: "Sellers upload dark, cluttered photos and their listings
  don't sell. They blame the platform."
- Thin answer: "Users need to upload photos." (restates the request, not pain)
- Acceptable: "There's no way to add images right now." (genuine gap)

**If research context exists:** Reference the known pain instead of
asking open-ended: "Research identified [pain]. Is that still the driver,
or has something changed?"

**If the answer restates the feature instead of the pain**, probe once:
"Got it — but what's the actual problem that causes? What goes wrong
for the user?"

Do NOT probe more than once. If the pain remains unclear after one
follow-up, note it and proceed.

**The challenge:** Based on the pain + codebase scan, surface one or two
implicit premises the user is making:

```
Before we lock this in — I notice two assumptions worth checking:

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]

Does the original framing still feel right, or should we adjust?
```

**What counts as an implicit premise:**
- "This needs a new screen" (maybe the existing screen can be extended)
- "This is a frontend problem" (maybe it's a data problem)
- "This is one feature" (maybe it's three, and only one matters now)
- "Users want this" (maybe they want something adjacent)
- "This needs to be built" (maybe it can be configured)

**What does NOT count** (don't waste time on these):
- Technical implementation choices (that's for planning)
- Architecture decisions (that's for spec or architect)
- Obvious facts about the codebase (already visible from scan)

**User responds in one of three ways:**

**"Framing is right."** → Proceed to Round 1 with the original request.
Note: `Framing: Original request confirmed. Pain: [stated pain].`

**"Let's adjust."** → User provides adjusted framing. Round 1 uses the
adjusted framing, not the original request.
Note: `Framing: Adjusted from [original] to [adjusted]. Pain: [pain].`

**"I don't know / let me think."** → Note uncertainty. Proceed with
original framing but flag it:
`Framing: Original request (low confidence). Pain: unclear.
Consider /research or /jtbd before building.`

From xoai/sage, MIT.

More from xoai/sage