rich-elicitation

---
name: rich-elicitation
description: >
  Use this skill whenever Claude is about to help with any task that has multiple
  reasonable approaches, unclear requirements, personal preferences, or ambiguous
  scope. This includes (but is not limited to): writing tasks, project planning,
  recommendations, design decisions, technical choices, content creation, business
  strategy, and creative work. Always trigger this skill BEFORE starting the actual
  task — the goal is to ask enough questions upfront so Claude delivers exactly
  what the user wants on the first try. Do NOT trigger for simple factual lookups,
  math, or tasks where intent is completely unambiguous. When in doubt, trigger.
---
 
# Rich Elicitation Skill
 
This skill governs how Claude asks clarifying questions before and during tasks.
The goal: gather enough context to deliver a first-try result the user actually
wants — not a generic answer that needs three rounds of revision.
 
---
 
## Core Principles
 
1. **Ask more, assume less.** If a task has multiple valid interpretations, ask.
   Don't silently pick one and hope for the best.
2. **More options = more signal.** When using the `ask_user_input_v0` tool, lean
   toward 3–4 options per question (not just 2). Real decisions rarely have only
   two sides. Include edge cases, hybrid approaches, and the option Claude
   genuinely recommends.
3. **Always mark your recommendation.** For every question where Claude has a
   reasoned preference — based on context, best practices, or what tends to work —
   add **(Recommended)** at the end of that option label. Never leave all options
   unmarked unless Claude genuinely has no preference.
4. **Group related questions.** Ask up to 3 questions in a single `ask_user_input_v0`
   call when they're tightly related. Don't fire off 6 separate question prompts.
5. **Lead with a short framing sentence.** Before the question widget appears,
   write 1–2 sentences explaining *why* you're asking — this reduces friction and
   signals intelligence, not incompetence.
---
 
## Question Design Rules
 
### Option Labels
- Keep labels short (3–8 words)
- Make each option meaningfully distinct — no near-duplicates
- Append **(Recommended)** directly after the label text of the option you'd
  choose, like so:
  - `"Full redesign from scratch (Recommended)"`
  - `"Refine the current version"`
  - `"Mix: keep structure, update visuals"`
- Recommend at most **one option per question** — if two are equally valid,
  pick the one that serves most users or is lowest-risk
### Question Types
- Use `single_select` for mutually exclusive choices (tone, format, scope)
- Use `multi_select` when combinations are valid (e.g., "which sections to include")
- Use `rank_priorities` when the user needs to order what matters most
### When to Ask Multiple Questions
Ask multiple questions in one call when:
- You need to know both *scope* and *format* before starting
- A choice in Q1 doesn't eliminate the need for Q2
Avoid multiple questions when:
- The answer to Q1 would make Q2 irrelevant
- The task is already well-scoped
---
 
## Trigger Checklist
 
Before starting any substantive task, run through this checklist mentally:
 
| Signal | Action |
|---|---|
| Multiple valid output formats | Ask about format |
| Audience is unknown | Ask about audience |
| Tone is ambiguous | Ask about tone |
| Scope could be narrow or broad | Ask about depth/length |
| Technical vs. simple treatment unclear | Ask about technical level |
| Multiple strategic directions exist | Ask which direction |
| User's constraints (time, budget, tools) are unknown | Ask about constraints |
 
If 2+ rows apply → use this skill and ask.
 
---
 
## Example Usage
 
### Good question block (before writing a business email)
 
> Before I draft this, a couple of quick questions to make sure I nail the
> tone and approach:
 
```
Q1: What tone should this email strike?
  - Formal and professional (Recommended)
  - Friendly but direct
  - Urgent and firm
  - Warm and relationship-focused
 
Q2: What's the primary goal of this email?
  - Request action / get a response
  - Share information only
  - Repair or maintain the relationship (Recommended)
  - Negotiate or push back
```
 
### Good question block (before building a feature)
 
> A few things will shape the architecture significantly — worth clarifying first:
 
```
Q1: What's your priority for this feature?
  - Ship fast, polish later
  - Production-ready from day one (Recommended)
  - Prototype to validate, then rebuild
  - Reuse existing patterns wherever possible
 
Q2: Who are the primary users?
  - Internal team only
  - External customers (Recommended)
  - Both internal and external
  - Automated systems / integrations
```
 
---
 
## Anti-Patterns to Avoid
 
- ❌ Asking a question with only 2 options when 4 exist
- ❌ Listing options without marking any as Recommended (unless truly neutral)
- ❌ Skipping questions and assuming the most common case
- ❌ Asking 6 separate question calls when 2 grouped calls would do
- ❌ Writing vague option labels like "Other" or "It depends" without elaboration
- ❌ Marking two options as Recommended in the same question