requirements-clarification

Requirements Clarification

Resolve only a remaining user-owned product decision. Do not turn normal implementation uncertainty into a question.

1. Read the request and any explicitly named or governing requirements source. Do not scan broadly for hypothetical ambiguity. If this evidence settles the outcome, proceed without asking.
2. Separate user-owned outcomes and authoritative inputs from agent-owned implementation choices. Research discoverable facts yourself. Never ask the user to choose a library, framework, or method the agent can determine.
3. If a narrow reversible default safely satisfies the request, state it and proceed. Complexity, greenfield status, file count, or integration work alone never requires clarification.
4. Otherwise ask before substantive commitment. Reads, notes, or one small branch-neutral probe are allowed; a scaffold, public contract, embedded domain values, or cross-system architecture is a commitment.
5. Prefer request_user_input when available. Ask one blocking outcome question; group at most three tightly coupled questions. Offer concrete outcome options and a recommendation. Never ask merely for permission to begin.
6. After the answer, do not ask again unless later evidence reveals a distinct material fork. Apply the answer and continue.

plan owns standalone plan and design deliverables. This skill does not create an approval gate or stop a specified implementation merely because planning would be useful. Never re-ask facts already supplied by the request or governing evidence, and never turn clarification into a refusal.