impact-selectlisted

# impact-select — what a change puts at risk The chain's other entry points start from a requirement. This one starts from **a diff**, which is what a developer has every day — a user story arrives once a sprint. That asymmetry, not the technique, is why this skill exists. ## The rule that keeps it honest **Say which of two questions you answered.** - *Grounded*: coverage data exists from a real instrumented run, so "these tests exercise this line" is a **fact**. - *Hypothesis*: no coverage data, so the answer comes from reading imports, fixtures and names. It is a **reading**, and it must be labelled as one on every line of the output. A selection presented as fact when it is a reading is the failure mode here: it tells a team it is safe to skip tests, on the strength of a guess. When in doubt, **over-select**. A test run for nothing costs seconds; a defect shipped because its test was deselected costs the trust that made anyone use the tool. ## The two questions to answer, in order 1. **What must be re-run?** The tests that touch the changed code, directly or transitively. 2. **What does the change leave uncovered?** The changed code that **no** test reaches. This is the output with the most value and the one nobody asks for. ## The dependency chain, and the step everyone forgets A Playwright suite reaches production code through three hops, and the middle one is where naive analysis fails: ``` spec file → fixtures → page objects / helpers → the appli