asking-clarifying-questions

# Asking Clarifying Questions

## Overview

Bridge the gap between raw user input and structured brainstorming by understanding what the user actually means, not what they said.

**Core principle:** Resolve contradictions first, then disambiguate. Conflicting goals must be reconciled before technical clarification - otherwise you're precisely defining the wrong thing.

**Announce at start:** "I'm using the asking-clarifying-questions skill to make sure I understand your requirements correctly."

## When to Use

Use this skill:
- After gathering initial context from user
- Before starting brainstorming or design exploration
- When user mentions technical terms that could mean multiple things
- When scope boundaries are unclear
- When assumptions need verification

Do NOT use for:
- Exploring design alternatives (that's brainstorming)
- Proposing architectures (that's brainstorming)
- Validating completed designs (that's brainstorming Phase 3)
- Asking for initial requirements (that's starting-a-design-plan Phase 1)

## Before Clarifying

Try to answer your own questions and disambiguate from the context of the working directory. Use available subagents, such as `codebase-investigator`, to explore for existing work that can help explain the the subject under clarification. When you recognize elements such as common technologies or proper nouns, use `combined-researcher` instead to synthesize both the codebase and internet searches.

You may have other skills or MCPs containing useful information, such as connections to remote datastores used for product management purposes. You should send out `haiku-general-purpose` subagents to investigate them when they're appropriate.

## What to Clarify

### 0. Contradictions (First Pass)

Before disambiguating technical details, scan for logical contradictions in requirements. If the user has stated mutually exclusive goals, resolve these first - technical clarification is wasted effort if the foundation shifts.

**Look for:**