/clarify

name: clarify
description: "Decomposes underspecified design requests by classifying gaps (missing brand context, visual ambiguity, false premises, scope faults) and generating targeted clarifying questions. Produces a confirmed design brief before any design work begins. For sharpening a design request that already exists; not for open-ended design brief discovery from a vague idea (use /design-for-ai:research)."
user-invocable: false

Skill: clarify

Understand what the user needs before committing to design work.

LLMs default to assuming rather than asking — models overwhelmingly proceed without asking even when information is missing. This skill serves as the design workflow's clarifier: it classifies what's unclear about a design request and generates targeted questions to resolve it before any visual or structural work begins.

`adaptive-questioning.md` at `${CLAUDE_SKILL_DIR}/references/adaptive-questioning.md` is a shared reference: the plan pipeline's clarify gates also link to it (design lifecycle checkpoints use it for mode-switching).

Your output is a conversation: clarifying questions, differential examples, restatements. Think out loud WITH the user — collaborative exploration, not interrogation.

---

Classifying What's Unclear

Not all gaps are the same. Classifying the type determines what kind of question to ask.

Fault Types

**Intention faults** — The real design goal isn't recoverable from the request.

• Vague objectives: "Make it look better" / "make it more modern" / "make it pop" (better how? for whom? in what direction?)
• Indirect intent: "Can you check if this color works?" (often means "please fix the color system")
• Contextual irrelevance: user introduces an unrelated visual concern mid-design

**Premise faults** — An assumption in the request is wrong or unresolvable.

• Missing brand context: "Match our brand" with no DESIGN.md, style guide, or reference supplied
• False artifact state: "Update the existing tokens" when no DESIGN.md exists in the project
• Capability mismatch: asking for a visual output the current context can't supply (e.g., "export as Figma" when only HTML is possible)

**Parameter faults** — Required design details are missing or conflicting.

• Missing register: "Design a landing page" (brand or product register? marketing or SaaS tool?)
• Missing audience/device: "Make it responsive" (primary breakpoints? phone-first or desktop-first?)
• Missing mood/personality: "Clean and professional" (minimal and cold? warm and approachable? editorial and bold?)
• Contradictions: "Keep it simple but show everything"

**Expression faults** — The language prevents unique design interpretation.

• Lexical ambiguity: "Clean up the UI" (reduce density? simplify color? tighten spacing? all of the above?)
• Scope ambiguity: "Make it more accessible" (WCAG AA contrast only? motion sensitivity? keyboard navigation? all three?)
• Referential ambiguity: "Update that component" (which one? in which context?)

Ambiguity Direction

Once you've identified a gap, classify which direction it pulls — this shapes your question:

| Direction | Signal | Clarification Action | |-----------|--------|---------------------| | **Semantic** | Design term has multiple valid meanings | Disambiguate: "do you mean X or Y?" | | **Too broad** | Clear intent but scope spans multiple pillars | Specify: "which concern matters most right now?" | | **Too narrow** | Request is oddly specific for the likely design goal | Generalize: "what's the broader outcome you're after?" |

For Design Tasks Specifically

Three concrete ways a design request becomes ambiguous:

• **Missing goal**: the *why* is absent — only the *what* is stated ("add a hero section" with no brief on purpose or audience)
• **Missing premises**: design constraints are unstated (brand colors, target device, tone, accessibility tier)
• **Ambiguous terminology**: vague design words used where precise ones are needed ("modern" vs "minimal + editorial", "professional" vs "product-register restrained")

Inconsistencies between design requirements are easy to miss. Explicitly check whether parts of the request conflict (e.g., "bold and vibrant" + "calm and trustworthy" pull in opposite directions).

---

Generating Questions

Think in Hypotheses

Don't start with "what should I ask?" Start with "what are the plausible design directions?" Then find the question whose answer eliminates the most of them.

1. Generate 2–4 competing design interpretations of the request 2. Identify what distinguishes them — the axis of disagreement 3. Ask about that axis

**Example:**

• Request: "Redesign the dashboard"
• Interpretation A: Reduce visual noise — strip cards, tighten spacing, neutral palette
• Interpretation B: Establish brand identity — introduce accent, typeface, personality
• Interpretation C: Improve usability — rethink hierarchy, surface key actions, reduce cognitive load
• Axis: is this a visual/brand problem, a clarity/usability problem, or a density problem?
• Question: "What's the main complaint about the current dashboard — it doesn't feel like the brand, it's hard to read, or it's overwhelming?"

One question targeting the axis of disagreement beats three questions about visual details.

Select for Information Gain

Among possible questions, ask the one that maximally reduces uncertainty across your interpretations. If question A would split your hypotheses 50/50 and question B would split them 90/10, ask A — it's more informative regardless of the answer.

Target convergence in 3–5 rounds. Beyond that, returns diminish sharply.

Concrete Over Abstract

When possible, show the user what different interpretations produce rather than asking abstract questions:

• Weak: "What kind of visual tone are you after?"
• Strong: "If you mean editorial — high contrast, tight spacing, expressive type — the palette leans into dark neutrals. If you mean approachable — rounded forms, warm color, ope