harms-check

# Harms Check Skill Design-time harm-to-users check — the safety-by-design lens the security/privacy/compliance gates structurally miss. Assumes the product works EXACTLY as designed. `/threat-model` (STRIDE) asks how an attacker breaks it; `/privacy-check` asks about personal data; neither asks: **who could this harm when it works as intended, and how could a legitimate feature be misused?** This is the design-time front-end of the BVSSH **Happier** dimension: a manipulative or harmful design is Happier-negative by definition, and this gate catches it before `/bvssh-check` would only measure it post-hoc. ## When to run (JiT — conditional, NOT universal) Fires only when the product-shape warrants it: - **User-facing** product/feature (real people use it), OR - has **persuasion / retention / conversion / cancellation / consent / pricing** flows (the dark-pattern surface), OR - **touches vulnerable people** (children, patients, financially- or otherwise at-risk). If none apply (internal dev tooling, a library, a build script), **SKIP — say so and move on.** This is a NUDGE, never a hard block. ## Workflow ### 1. Dark / deceptive patterns (Brignull) — does the design manipulate the user? Check the design against the recognised, regulated catalog (deceptive.design; FTC / EU Digital Fairness Act / GDPR-consent): - [ ] **Obstruction / roach motel** — easy to get in, hard to cancel, leave, or delete - [ ] **Sneaking** — hidden costs, drip pricing, sneak-into-basket, hidden s...