clarify-scopelisted

# Skill: clarify-scope Turn a vague testing request into a brief precise enough to build from. "Add tests for checkout" contains at least eight unresolved decisions. Answering them silently means building the wrong thing confidently; asking all eight at once is a form to fill in, which people abandon. So: one question at a time, each carrying a recommended answer, and every question that is really a lookup gets looked up instead of asked. *The one-question-at-a-time interrogation pattern here is adapted from Matt Pocock's "grilling" technique, narrowed to test-automation scoping.* ## When to use - Real forks are open: which layer, which environment, whether negative paths are in scope. - The request names a feature rather than a behaviour. - The work is large enough that building the wrong thing costs more than the conversation. **Skip it** when there is one obvious behaviour, one obvious layer, and an existing pattern to copy. Interrogating someone who asked for a clearly specified test is its own kind of failure. ## The rules 1. **One question, then wait.** Not two, not a numbered list. Absorb the answer before forming the next question — later questions usually change shape based on earlier ones. 2. **Look up facts; ask only about decisions.** Whether a model already exists for that screen, what the environments are called, which data file holds the credentials, what the neighbouring specs do — all discoverable. Read the repo. Asking a user something the r