Skip to main content
skill CX Codex

privacy-check — Claude Code skill: what it does, how to install

Evaluates features and systems against Privacy by Design principles and GDPR rules. It audits data collection flows and logs risks into a canvas file.

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

What privacy-check does

This skill audits system designs against Cavoukian's seven foundational Privacy by Design principles. It examines whether privacy is the default setting, checks end-to-end security measures, and verifies consent handling. The workflow also builds a personal data inventory detailing retention limits, lawful bases, and external data processors.

All findings go into .claude/canvas/privacy-assessment.yml as the single source of truth, followed by an entry in .claude/harness/decision-log.md. A built-in postflight check reads the canvas file immediately after writing. This step prevents reporting success when timestamps update without actual field changes.

Running this skill without the mycelium framework disables canvas state management, theory gates, and harness behaviors.

What it helps with

  • audit feature architectures against GDPR and data protection rules
  • build an inventory of collected personal data fields and processors
  • verify privacy controls act as system defaults before implementation
  • document data protection impact risks directly in project canvas files

Example prompts for the agent

  • Run a privacy check on our user onboarding workflow and record the canvas
  • Assess our payment processing pipeline against Privacy by Design principles
  • Generate a data inventory and check GDPR alignment for the export feature

How to install privacy-check

1Skills CLI (Vercel)

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

2Manually: put the files in place

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

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

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

Questions about privacy-check

How to install privacy-check in Claude Code?

Run npx skills add haabe/mycelium --skill privacy-check -a claude-code in your terminal.

What does the privacy-check skill do?

It conducts a Privacy by Design assessment across seven core principles and GDPR requirements. Findings and data inventories are verified and saved to .claude/canvas/privacy-assessment.yml.

Can privacy-check run without the mycelium framework?

It can run standalone, but it will bypass canvas state checks, theory gates, and harness logging. The author recommends installing the mycelium plugin via /plugin install mycelium@haabe-mycelium.

Source text

SKILL.md · MIT
---
name: privacy-check
description: "Use to assess Privacy by Design compliance and GDPR/data protection alignment for a feature or system."
metadata:
  instruction_budget: "37"
  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."
---

# Privacy Check Skill

Privacy by Design assessment.

## Workflow

### 7 Foundational Principles (Cavoukian)

1. **Proactive not Reactive**: Are privacy measures built in from the start?
   - [ ] Privacy considered in design phase, not bolted on
   - [ ] Risks identified before implementation

2. **Privacy as Default**: Is the most private option the default?
   - [ ] Data collection opt-in, not opt-out
   - [ ] Minimum data collected by default
   - [ ] Sharing disabled by default

3. **Privacy Embedded in Design**: Is privacy integral to the system?
   - [ ] Privacy controls are core features, not add-ons
   - [ ] Architecture supports data minimization

4. **Positive-Sum, not Zero-Sum** (originally "Full Functionality"): Privacy without trade-offs?
   - [ ] Privacy features don't degrade user experience
   - [ ] Not a false choice between privacy and functionality
   - [ ] Avoid false dichotomies: privacy vs. security, privacy vs. business value

5. **End-to-End Security**: Data protected throughout its lifecycle?
   - [ ] Stored and sent the way the data needs: encryption where personal data is stored or sent electronically; for paper or in-person handling, who holds it and where (v0.271.0)
   - [ ] Secure deletion when no longer needed
   - [ ] Access controls throughout the data lifecycle

6. **Visibility and Transparency**: Is data processing transparent?
   - [ ] Users know what data is collected and why
   - [ ] Processing purposes documented and communicated
   - [ ] Third-party sharing disclosed

7. **Respect for User Privacy**: Are user interests centered?
   - [ ] Users can access their data
   - [ ] Users can correct their data
   - [ ] Users can delete their data
   - [ ] Consent is informed, specific, and revocable

### Data Protection Assessment

**If the product holds no personal data, say so in the data inventory, with how you know** (a
page that stores nothing, a book): the principles above then need only a line each confirming
nothing is collected. Controls are proportional to what is held; none are defaults (v0.271.0).

- **What data is collected?** List all personal data fields.
- **Why?** Lawful basis for each data element.
- **How long?** Retention period for each data type.
- **Who accesses it?** List all parties with access.
- **Where is it stored?** Data residency and cross-border transfers.
- **How is it protected?** Encryption, access control, monitoring.
- **What if breached?** Incident response plan exists?

### Output

```
## Privacy Assessment: [Feature/System]

### PbD Principles
| Principle | Status | Notes |
|-----------|--------|-------|
| Proactive | Pass/Fail | ... |
| Default privacy | Pass/Fail | ... |
| Embedded | Pass/Fail | ... |
| Full functionality | Pass/Fail | ... |
| End-to-end security | Pass/Fail | ... |
| Transparency | Pass/Fail | ... |
| User respect | Pass/Fail | ... |

### Data Inventory
| Data | Purpose | Basis | Retention | Protection |
|------|---------|-------|-----------|-----------|
| ... | ... | ... | ... | ... |

### Risks and Recommendations
1. [risk and recommended action]
```

## Canvas (MANDATORY — the source of truth, do this FIRST)

`.claude/canvas/privacy-assessment.yml` is the canonical record. The decision log is provenance; the
canvas is what the framework READS. Write the canvas before the decision log — if only one of the two
lands, it must be this one.

**WHY THIS SECTION EXISTS (v0.170.0).** On the dogfood project this file carried
`last_assessed: 2026-05-04` while **all seven** Privacy-by-Design principles read
`assessment: not-assessed` with empty `evidence`, and `data_inventory` was empty. **A date asserting
an assessment that never landed is worse than an empty file**: a reader checking freshness sees an
assessed record, and the `Privacy` theory gate — Required at L2-L4 — reads it. Never stamp
`last_assessed` in a run that does not also fill the principles.

**UPDATE each of the seven keys in `principles`** (`proactive_not_reactive`, `privacy_as_default`,
`privacy_embedded`, `full_functionality`, `end_to_end_security`, `visibility_transparency`,
`respect_for_users`):

```yaml
  <principle_key>:
    assessment: pass|partial|fail|not-assessed
    evidence: "<what was observed, and where>"
```

**Then:** `data_inventory` (what personal data the product actually touches — an empty list is a
CLAIM that it touches none, so make it deliberately), `processors` (every party outside the product
that receives or stores that data, with `role`, `data_types`, `location`, `retention_period` and
`agreement`: the answers to "Who accesses it?" and "Where is it stored?" above), `dpia_required` +
`dpia_rationale`, and `last_assessed`.

**A reassessment updates these same fields; it does not add a new block.** What changed, and why,
goes in the decision-log entry below. The schema rejects any root key it does not name, and from
v0.250.0 the write is checked as it lands.

**`last_assessed` IS A CLAIM ABOUT THE PRINCIPLES BELOW IT.** Set it only when they were filled in
the same run. If the assessment is partial, say which keys were judged in `dpia_rationale` rather
than dating the whole file.

## Postflight: Verify-After-Write (write-narration-verification discipline)

**Hard rule** (per the operating contract's Communication Rules, anti-pattern #7 Stage 2 graduation). Before any
user-facing summary claims the assessment was recorded, use the **Read tool** on the canvas file and
confirm the VALUE fields above actually changed — not just `_meta.last_validated`. A stamp moving
while the assessed fields stay at their defaults is the exact failure this skill shipped with: the
file reads fresh and holds nothing. Preflight protects what gets written; Postflight protects what
gets claimed about what was written.

## Decision Log (MANDATORY per G-P4)
**APPEND** a `### Privacy Assessment` entry to `.claude/harness/decision-log.md` with: principles assessed, data flows identified, risks found, GDPR compliance status.

## Theory Citations
- Cavoukian: Privacy by Design (7 principles)
- GDPR: Data protection regulation

© haabe · MIT · haabe/mycelium

Similar skills

All skills for Security →

From the same set58

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