/privacy-check

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?

• [ ] Encryption at rest and in transit
• [ ] 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

• **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`):

  <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), `dpia_required` + `dpia_rationale`, and `last_assessed`.

**`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 CLAUDE.md 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