clarifylisted

# Clarify a Specification Find where a specification is ambiguous or silent, ask the smallest number of questions that resolve the highest-impact gaps, and write every answer back into the spec so the document — not the chat transcript — carries the decision. This runs after a spec exists and before anyone builds against it. Ambiguity caught here costs one question; ambiguity caught during the build costs a rebuild. The person answering is a product manager, business owner, or domain expert — expert in the business, not in software construction. Every question must be answerable from what they know about their own operation. A question they'd need an engineer to answer is a question you shouldn't be asking. **Never invent a specific number, threshold, name, or percentage they haven't given you.** Turning a vague adjective into a number is the single most valuable thing this skill does — but the number has to come from them. Proposing "under two seconds" to someone with no target in mind produces agreement, not information, and a figure you made up is then indistinguishable in the spec from one the business actually committed to. Ask what they'd expect, or what they measure today; if they genuinely don't know, record the shape and leave the figure as `[NEEDS BASELINE]`. `[NEEDS BASELINE]` is a sanctioned marker meaning "not currently measured", written by this skill and by write-spec. It is the legacy spelling of `[NEEDS MEASUREMENT]`, defined canonically in `../../CONVEN