designlisted

# Design the tests Input: `$ARGUMENTS`. A path to a refined requirement, a ticket key, or nothing, in which case ask which requirement. The output is a table of conditions with a decision attached to each one. Every row says what to check, why it matters, where it belongs, and whether it gets automated. Rows that say "do not test this" count. ## Steps **1. Read the setup.** Run `qa-context`. The `layout` and `policies` in the profile decide what an automatable row actually looks like, and which layers this project has at all. **2. Read the requirement.** If it has not been through `/qa:refine`, do that first. Designing against an ambiguous requirement produces a design that has to be redone. **3. Find the shape.** Use `test-design-techniques`. For each acceptance criterion, work out which shape it is (range, set, rules, lifecycle, combinations, flow) and apply the matching technique. One requirement usually has several shapes in it. **4. Look at what already exists.** Before adding a row, check whether the suite already covers it. Use `layout.tests` and `layout.test_glob` from the profile to find the tests, and grep for the behaviour, not the file name. Duplicate coverage is the second most common finding in a suite audit, after sleeps. **5. Score each condition.** Likelihood times cost, both 1 to 3. See `references/risk.md` in `test-design-techniques`. **6. Pick the layer.** Push every check to the lowest layer that can see it. A validation rule tested through the b