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 subscription
• Forced continuity / forced action — silent auto-renew; forced account/consent to proceed
• Confirmshaming — guilt/shame wording to steer a choice ("No, I don't want to save money")
• Nagging — repeated interruption until the user relents
• Misdirection / visual interference — pre-ticked boxes, manipulative default, tricked hierarchy
• Privacy zuckering — coaxing users to share more than intended; consent dark patterns
• Bait and switch / disguised ads — the control does something other than advertised

Any hit = the design manipulates or coerces → Happier-NEGATIVE. Redesign for the honest default.

2. Consequence scanning (doteveryone) — intended AND unintended

• Intended consequences — which to amplify?
• Unintended consequences (assume it works as designed and scales) — which to mitigate?
• Who could this harm — including vulnerable users AND non-users / third parties / society?
• Who is least able to absorb the harm?

3. Foreseeable misuse (harms modeling) — weaponising a legitimate feature

• How could a bad actor use this feature-working-as-designed to harm someone (harassment, stalking, fraud, coercion)?
• What reasonably-foreseeable "unsupported uses" create harm?

Output

## Harms Check: [Feature/Product]

Scope trigger: [user-facing | persuasion/retention flow | vulnerable users | N/A — skipped]

### Deceptive patterns
| Pattern | Present? | Honest redesign |
|---------|----------|-----------------|
| ... | yes/no | ... |

### Consequences & foreseeable misuse
| Harm | Who (incl. non-users / vulnerable) | Working-as-designed or misuse | Mitigation |
|------|------------------------------------|-------------------------------|-----------|
| ... | ... | ... | ... |

### Happier verdict
[net-positive for the user | Happier-NEGATIVE — redesign]

### Recommendations (NUDGE — advice, not a block)
1. ...

Honest limits (scope guard)

This gate educates a builder who reached for a manipulative pattern without seeing the harm; it cannot stop a builder who deliberately wants to manipulate. It is a NUDGE keyed to product-shape — not a trust-&-safety / content-moderation apparatus. Online-content harms (CSAM, disinformation, hate speech) are out of scope and belong to specialised tooling, not Mycelium.

Decision Log (MANDATORY per G-P4)

APPEND a ### Harms Check entry to .claude/harness/decision-log.md with: the scope trigger, any deceptive patterns found, foreseeable-misuse / vulnerable-user harms, the Happier verdict, and mitigations accepted or waived.

Theory Citations

• Brignull: Deceptive (Dark) Patterns
• doteveryone: Consequence Scanning
• Microsoft: Harms Modeling (foreseeable misuse; vulnerable- and non-user harm)
• Smart: BVSSH — the "Happier" dimension (this gate is its design-time front-end)
• eSafety / WEF: Safety by Design (anticipate harm before it occurs)