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.
npx skills add haabe/mycelium --skill harms-check -a claude-codeWhat 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-code2Manually: put the files in place
~/.claude/skills/harms-check/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/harms-check/
1Skills CLI (Vercel)
npx skills add haabe/mycelium --skill harms-check -a codex2Manually: put the files in place
.agents/skills/harms-check/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add haabe/mycelium --skill harms-check -a cursor2Manually: put the files in place
.cursor/skills/harms-check/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install haabe/mycelium harms-check2Manually: put the files in place
.github/skills/harms-check/SKILL.md1Skills CLI (Vercel)
npx skills add haabe/mycelium --skill harms-check -a gemini-cli2Platform CLI
gemini skills install https://github.com/haabe/mycelium --path plugins/mycelium/skills/harms-checkManually: put the files in place
.devin/skills/harms-check/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add haabe/mycelium --skill harms-check -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
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