privacy_by_design v1.0.0

name: "privacy_by_design" description: "Build privacy into a product from the start: data minimization reviews, retention schedules, consent flows, and the deletion-request drill. Triggers when someone asks about privacy by design, GDPR-style data practices, retention policies, handling delete-my-data requests, or privacy reviews of a feature."

Privacy by Design

Purpose

Apply the privacy-by-design approach to a real product or feature: find what personal data is collected, cut what is not needed, set retention with real deletion, design consent people can actually withdraw, and rehearse the deletion request before one arrives. Grounded in Ann Cavoukian's seven foundational principles and the GDPR's operational rules (Articles 5, 7, 17, 25), but written as an engineering checklist, not a legal memo. This is not legal advice; it is a working method that happens to line up with what regulators ask for.

Workflow

1. Inventory. List every personal data field the system touches: field, where it is stored, where it goes (third parties), why it was collected, lawful basis. Without this inventory (GDPR calls it Records of Processing Activities, Article 30) every deletion request is guesswork. Use references/data-inventory-template.csv.

1. Minimize. For each field, ask: can this feature work without it? Collect the smallest set that still delivers the feature. Cut fields collected "in case we need them later". See references/minimization-patterns.md for concrete tactics (aggregation, coarse buckets, local-first processing, pseudonymization).

1. Set retention with real deletion. Give every data category a retention period and a reason. Deletion must actually remove the data, not flip an is_active flag. Run bin/retention_audit.py against the inventory CSV to catch missing periods, indefinite retention, and soft-delete-only stores.

1. Make privacy the default. New users land on the private setting. Optional fields are never required. Tracking, analytics, and marketing hooks are off unless the user turns them on. Public visibility always requires an explicit action.

1. Design consent that counts. Consent must be freely given, specific, and unambiguous, in plain language. Withdrawing it must be as easy as giving it. Never bundle consent for unnecessary data into a contract or signup gate. See references/consent-patterns.md.

1. Rehearse the deletion request. Work the drill in references/deletion-drill.md: verify identity without collecting new data, check lawful-basis exceptions (Article 17 exemptions: legal obligation, freedom of expression, public health, archiving/research, legal claims), delete across every store including where backups would resurrect the data, notify recipients who got the data, and confirm within the statutory window.

1. Verify on the surface. Re-run the audit CLI. Actually delete a test record and query every store for it. Confirm the defaults by signing up fresh and checking what is public.

Output Contract

• A filled data-inventory.csv covering every personal data field.
• A retention schedule: category, period, reason, deletion mechanism, verification method.
• Passing bin/retention_audit.py output (zero FAILs, or listed waivers with owner and date).
• A consent-flow review: where consent is asked, what it covers, how it is withdrawn, and the no-bundling check.
• A worked deletion-drill log for one representative user record.

Operating Rules

1. Every factual claim about the law cites an article or an authoritative source. Unverifiable = cut it or frame it as opinion. No confident unverified claims, ever.
2. The skill is about process, not jurisdiction trivia. It applies the same discipline whether or not GDPR formally applies; never claim a specific law applies to someone else's product without saying so is uncertain.
3. Default-deny on exemptions: the Article 17 exemptions are the exception, not the rule. When one blocks deletion, write down which exemption, why, and the exact date the data does get deleted.
4. Soft delete is not deletion. If a store cannot hard-delete, document the workaround (e.g. purge on backup rotation, tombstone keying) and its worst-case resurrection window.
5. Never collect more data to satisfy a privacy request than the request needs: verifying a deletion requester's identity must not become a new data collection event.
6. Keep the skill out of legal-advice territory. Phrase guidance as engineering practice that aligns with regulator expectations; when legal judgment is required, say so plainly and stop.
7. No em dashes. No ChatGPT-speak. Plain direct language everywhere, including generated templates and reports.