Skip to main content
skill CX Codex

harms-check — Claude Code skill: catch design-level harm early

A skill that scans a user-facing product for deceptive patterns and foreseeable misuse before release, the harms that security and privacy gates don't look for.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add haabe/mycelium --skill harms-check -a claude-code
Open on GitHub

What harms-check does

The check assumes your product works exactly as intended and then asks who that could hurt. It walks three passes: the Brignull catalogue of dark patterns (roach motel, drip pricing, confirmshaming, pre-ticked boxes), consequence scanning in the doteveryone style that counts non-users and bystanders, and foreseeable misuse — how a legitimate feature gets turned against someone.

It fires conditionally. Triggers are a real user-facing surface, flows around persuasion, retention, cancellation, consent or pricing, or anything touching vulnerable people. For internal tooling, a library or a build script the skill says skip it and note why. Findings come out as tables plus a verdict: net-positive for the user or Happier-negative, with redesign advice.

The skill is built to run inside the Mycelium framework; on its own it skips canvas state, the theory gates and writing the verdict into .claude/diamonds/active.yml. It educates a builder who reached for a manipulative pattern without noticing the harm. It won't stop someone who means to manipulate. Nothing is blocked either — a Happier-negative verdict still lets the release through.

What it helps with

  • spot dark patterns on a checkout or subscription screen
  • check whether cancelling is harder than signing up
  • map who gets hurt by a feature that works as designed
  • review how a legitimate feature could be abused by someone else
  • record in the decision log that a harms check does not apply

Example prompts for the agent

  • Run harms-check on the cancellation flow — is it too hard to leave?
  • Do a harms-check on the consent screen for data sharing
  • Run harms-check on the recommendation feature for minors

How to install harms-check

1Skills CLI (Vercel)

npx skills add haabe/mycelium --skill harms-check -a claude-code

2Manually: put the files in place

~/.claude/skills/harms-check/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/harms-check/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about harms-check

How do I install harms-check in Claude Code?

Run npx skills add haabe/mycelium --skill harms-check -a claude-code. The skill lands at ~/.claude/skills/harms-check/SKILL.md.

What does harms-check do?

It looks for manipulative interface patterns, scans consequences and reviews foreseeable misuse. You get a Happier verdict and a list of fixes.

Do I need harms-check for an internal tool?

No. When real people never see the product and there are no persuasion, retention or consent flows, the skill tells you to skip and log the reason.

Source text

SKILL.md · MIT
---
name: harms-check
description: "Use when building anything USER-FACING (or with persuasion/retention/cancellation/consent/pricing flows, or that touches vulnerable people) to surface design-level harm the security/privacy/compliance gates miss: dark/deceptive patterns and foreseeable misuse. Assumes the product works as designed and asks who it could harm and whether it is Happier-negative. NUDGE, not a block."
metadata:
  instruction_budget: "44"
  framework_dependency: "mycelium"
  framework_dependency_note: "This skill is designed to run within the Mycelium framework (https://github.com/haabe/mycelium). Standalone use will skip the canvas state, theory gates, and harness behavior the skill assumes. Install: /plugin install mycelium@haabe-mycelium."
---

# 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.

**At release, the framework asks for it (v0.321.0).** When work that reaches real people has an exposure record on its diamond and no harms check recorded there, the release path says so in one advisory line: in the release gate's refusal, in `scale_locks.py --exposure-state`, and as context when a release is allowed. That line is the prompt to run this skill, or to record that it does not apply. It never refuses anything, and a Happier-negative verdict does not stop a release.

## 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. ...
```

## Record the verdict on the exposure (v0.321.0)

When the diamond carrying this work has an exposure record (`exposures[]` in `.claude/diamonds/active.yml`), write the result on the record this check was run for:

```yaml
harms_check:
  'on': '2026-10-11'             # the date the check was run; quote both (a bare `on` is a YAML 1.1 boolean)
  verdict: net-positive          # net-positive | happier-negative | not-applicable
  note: "what was found, or why it does not apply"
```

- `not-applicable` is the SKIP above, written down: use it when none of the scope triggers apply, and put the reason in `note`.
- `happier-negative` is recorded as it is. It does not stop a release. The person decides whether the work goes out as designed, and the release path reminds them of the verdict when it does.
- It is not one of the exposure's `gates`, and nothing reads it to allow or refuse anything. Without it, the release path keeps saying that no harms check is recorded for that exposure.
- Use the Read tool on `.claude/diamonds/active.yml` before editing it, and change only this key.
- No exposure record yet (the work has not been put in front of anyone): the decision-log entry below is the whole record.

## 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)

© haabe · MIT · haabe/mycelium

Similar skills

All skills for Security →

From the same set18

ping A smoke test that answers with one marker line when the Mycelium plugin is packaged and wired up correctly. Not meant for everyday use. CX Codex +1 ★ 47repo stars mocked-persona-interview For solo and hobby projects where real user interviews are off the table: the skill runs interviews with invented personas and keeps them from becoming a rubber stamp for your own assumptions. CX Codex +1 ★ 47repo stars metrics-detect Scans the repo and sets up adapters for the metric sources your product actually uses, from GitHub to Stripe. Handy when the project predates this setup. CX Codex +1 ★ 47repo stars jtbd-map Splits customer work into functional, emotional and social jobs, then saves the map to a canvas file. CX Codex +1 ★ 47repo stars friction-log Drafts an honest write-up of where working with Mycelium felt confusing or slow. You edit it and decide whether it goes anywhere. CX Codex +1 ★ 47repo stars fan-out Spawns several subagents on one problem, then folds their findings into a single pick. Useful when two or more solutions compete and you need evidence, not a guess. CX Codex +1 ★ 47repo stars diamond-render Turns .claude/diamonds/active.yml into a picture of the decisions recorded so far, in order, plus the ones still ahead. Useful at the end of an assessment. CX Codex +1 ★ 47repo stars devils-advocate Puts a pending decision through pre-mortem, reversed assumptions and a blind adversarial pass, so a weak premise shows up before it ships. CX Codex +1 ★ 47repo stars

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor