refinelisted

# Refine a requirement Input: `$ARGUMENTS`. A ticket key, a path to a file, a URL, or pasted text. The output of this is not test cases. It is a requirement someone can build from and someone else can test against, plus a short list of things nobody decided yet. That second list is the whole point. A requirement that survives this without producing a single question was either already excellent or was not read carefully. ## Steps **1. Read the setup.** Run `qa-context`. You need `tracker` and `requirements` to know where the source is, and `project.glossary` if there is one, so the output uses the words the business uses. **2. Get the source.** Depending on `requirements.source`: - `jira` or `confluence`: use the Atlassian tools. Fetch the item, and also its linked items and comments, the decisions usually live in the comments. - `github-issues`: `gh issue view <n> --comments`. - `markdown`: read the file under `requirements.path`. - Pasted text: use it as is. Also read whatever the requirement points at: a design file, a linked spec, the API contract. And look at the code if it exists, because the gap between what the ticket says and what the code does is a finding on its own. **3. Restate it.** In two or three sentences, what changes for a user when this is done. If you cannot write that without hedging, the requirement is not ready and the rest of this is guesswork. Say so. **4. Find the holes.** Go through the requirement looking for: - Words that hide a decis