Implement Privacy by Design Principles

This skill integrates privacy protections into software architecture from the beginning rather than as an afterthought, applying Privacy by Design principles (GDPR Article 25, Cavoukian's framework) when designing databases, APIs, and user flows. It covers six core principles - data minimization (collect only what's justified), purpose limitation (store and respect the stated purpose of each data point), storage limitation (define retention periods with automated deletion), privacy as default (opt-in not opt-out, no pre-checked consent boxes), end-to-end security (encryption, RBAC, access logging), and transparency (clear privacy policies, easy access/deletion) - and maps GDPR user rights (access, rectification, erasure, portability) to concrete implementation patterns. It provides code examples for minimal user models, consent-gated analytics tracking, PII-safe logging, retention-documented SQL schemas, and allowlisted API responses.

Use it when building apps that collect personal data (names, emails, locations, preferences), when designing database schemas, APIs, or authentication flows, when a user mentions forms, user accounts, analytics, or third-party integrations, or when verifying privacy controls before a production deployment. It references GDPR (EU, primary reference), CCPA (California), and LGPD (Brazil) - the guidance is to design for the strictest framework you target, since that often satisfies the others.

Do not log passwords, tokens, or PII in plain text - use redaction or hashed identifiers instead. Do not share data with third parties without explicit consent, and audit every dependency that touches user data before adding it (what it collects, where it sends data, whether it loads before consent). Do not assume "we'll add privacy later" - the skill's premise is that this rarely happens and privacy must be designed in from day one. Treat its output as a design checklist to apply with judgment, not a substitute for environment-specific legal or compliance review.

Input: a description of the feature, schema, or flow that touches user data. Output: privacy-by-design guidance with a data-necessity checklist and code-level fixes.

### BAD: Logging PII in plain text
logger.info(f"User {user.email} logged in from {request.remote_addr}")

### GOOD: Redact or hash identifiers
logger.info(f"User {hash_user_id(user.id)} logged in")

Applies directly to database schema design (documenting purpose and retention per column), API response shaping (explicit field allowlists), authentication/consent flows, structured logging, and third-party SDK/dependency audits (analytics, crash reporting, ads).

Developers and architects designing or reviewing systems that collect personal data, who need concrete GDPR/CCPA/LGPD-aligned patterns for minimization, consent, retention, and PII-safe logging built in from the start rather than retrofitted before launch.