clarifylisted

# Clarify Turn a vague request into a crisp, agreed need **before** classifying or acting — the way a good analyst does: reflect, ask the sharpest question, listen, repeat. This is a **reflex**, always in the agent's memory (see the Clarify step in `AGENTS.md`), not a workflow stage — it fires on *any* request, including bug reports and change requests on an existing project ("the login page doesn't display well, users can't sign in"). ## When to use Whenever a request is ambiguous or under-specified and acting on it would mean guessing: - a **vague symptom** ("doesn't work", "displays badly", "is slow") with no observable, testable meaning; - **missing acceptance** — you can't yet name what "done" looks like; - **several plausible readings** that would lead to genuinely different work; - **unclear scope or users** ("everyone"? one browser? mobile only?); - a request that **contradicts the spec** or a best practice — clarify the intent before complying. Skip it when the request is already unambiguous and testable — over-questioning is its own failure. ## Method — reflect, then one question at a time 1. **Acknowledge, then reflect it back — warmly and naturally.** Open by showing you've taken the request on board, then lead into the clarification as a way to serve it *better* — never as an interrogation. Restate the request in one sentence, name the goal as you understand it, and surface your assumptions so a wrong one is easy to correct. Vary the wording every ti