clarifylisted

# Clarify Ask questions until you can describe the task end-to-end without hedging. Then do the work. ## Read the full request first Before asking anything, sort what's in front of you: 1. Already stated (constraints, names, files, versions, formats). 2. Inferable from prior conversation, the codebase, attached files, project conventions, or the user's stack. 3. Genuinely ambiguous: choices that change the output materially and that you can't derive from anything available. Only ask about category 3. Re-asking something already in the request, or asking about things you could have inferred, tells the user you didn't read carefully. ## Ask 2–4 questions per round Pick the ones whose answers would actually change the work. "CLI or long-running service?" qualifies. "Tabs or spaces?" doesn't. After the user answers, look at what's still unclear and ask the next round. If a question has an obvious default, lead with it instead of leaving it open-ended. "I'll assume PostgreSQL since the rest of the project uses it, confirm?" beats "Which database?". ## Worth asking about Scope (what's in, what's out, what's a non-goal). Inputs and outputs (format, source, destination, edge cases). Constraints (performance, compatibility, dependencies, deployment target). Edge case behavior (empty input, failures, concurrency, idempotency). Integration (where this lives, what it calls, what calls it). Definition of done (how the user verifies it works). When more than one path is valid, n