prioritizelisted

# prioritize — risk-based, human-arbitrated Follow the shared contract in `../README.md`. Prerequisite: `03-design.md` (else offer `istqb-design`). Risk-based testing needs inputs only a human has — how much a failure would actually cost this business, and how fragile this part of the system really is: **the skill proposes, the user decides.** ## Steps 1. **Propose scores.** For each test condition of `03-design.md`: - **Impact (1-3)** — consequence if this behavior fails in production. Safety, regulatory or data-loss = 3; degraded service = 2; cosmetic = 1. Use `knowledge/` (criticality notes, anomaly history) when available, and cite what you used. - **Probability (1-3)** — likelihood of a defect. New, complex or concurrent logic and `[open]`-flagged conditions score higher; stable, well-understood rules lower. - **Optional git-history signal** — see `references/git-history-signal.md`. Only when the user has explicitly named a target repo path for this session. - **Priority = impact × probability** → **P1 (≥ 6) / P2 (3–5) / P3 (≤ 2)**. 2. **Show your reasoning compactly.** One table: condition, impact, probability, priority, one-line rationale. Flag every score resting on an `[assumption]` or `[open]` item, and every score whose probability the git-history signal nudged — citing the files and stat used (`@history(path, stat)`). Same visibility rule as `[assumption]`/`[open]`: **an uncited influence is not usable.** 3. ⚠ V