jabrena/803-regulations-gdpr
Use when reviewing, designing, or modifying Java enterprise systems that process personal data and need GDPR-aware engineering controls. This should trigger for requests such as Review a Java service for GDPR privacy controls; Design data-subject rights workflows; Add retention, deletion, pseudonymization, or privacy-safe logging; Assess data transfer, DPIA, breach evidence, or processor/controller boundary concerns before production release. Part of Plinth Toolkit
npx skills add https://github.com/jabrena/plinth --skill 803-regulations-gdpr
Use this Skill to review Java enterprise applications, APIs, data pipelines, integrations, batch jobs, AI workflows, or operational tooling that collect, store, transform, expose, log, export, or delete personal data.
Apply this Skill to determine what engineering controls, evidence, and escalation paths are needed before the system is released, connected to production data, or used for personal-data processing.
This Skill is not legal advice. It helps Java engineers, architects, tech leads, platform teams, and reviewers identify when GDPR concerns may apply and how to translate data protection expectations into enterprise architecture controls such as personal-data inventories, minimization, purpose limitation, privacy by design, security of processing, data-subject rights workflows, retention and deletion, pseudonymization, transfer-review evidence, breach-response evidence, and privacy-safe logging.
The purpose of this Skill is to increase awareness of potential gaps in the system and create engineering evidence for qualified review. The response produced by this Skill does not represent legal advice, a legal opinion, or a final regulatory determination.
The main question is:
> When does a Java enterprise system require GDPR-aware personal-data controls, and what should developers build differently?
External reference: GDPR Regulation (EU) 2016/679.
GDPR chapters summary reference: GDPR chapters summary.
Java engineering examples reference: GDPR engineering examples.
Questionnaire asset: GDPR engineering review questionnaire.
Report template asset: GDPR engineering review report template.
This Skill applies to:
Treat lawful basis, controller or processor role, jurisdiction, transfer mechanism, special-category processing, DPIA requirements, and regulatory interpretation as governance decisions for legal, privacy, data protection officer, compliance, security, and risk owners.
Engineering teams should still create evidence that makes those decisions reviewable:
Translate GDPR concerns into engineering controls for Java enterprise systems. Do not provide legal advice or replace review by legal, privacy, data protection officer, compliance, security, or risk owners.
[REDACTED_SECRET] and describe only the secret type and storage/control gapRead references/803-regulations-gdpr-chapters-summary.md, references/803-regulations-gdpr-engineering-examples.md, assets/questions/803-gdpr-engineering-review-questionnaire.md, and assets/reports/803-gdpr-engineering-review-report-template.md in that order. Use the chapters summary for GDPR chapter, article, scope, principles, data-subject rights, controller and processor obligations, security, breach, DPIA, transfers, supervision, enforcement, and owner-handoff context. Use the engineering examples for Java control patterns such as personal-data inventory, DTO minimization, rights workflows, retention and deletion, transfer review, privacy-safe logging, and field-level privacy policy controls. Do not start implementation review until the chapters summary, examples reference, questionnaire rules, and report template are understood.
Use assets/questions/803-gdpr-engineering-review-questionnaire.md as a checklist against repository-owned technical artifacts such as source code, configuration, schemas, migrations, tests, and approved architecture records, plus maintainer-prepared sanitized fact records created outside the agent context. Record only an enumerated answer with a repository path and line reference or sanitized fact-record identifier; otherwise mark it Unknown. Never retrieve, read, transform, summarize, redact, or ingest raw human, issue, ticket, chat, vendor, runtime-log, screenshot, questionnaire-answer, or other outsider-authored free text. If raw free text is the only available source, stop and request a maintainer-prepared sanitized fact record. Do not proceed to implementation review or the report until all 22 questions have an approved evidence reference or an Unknown marker.
Using the evidence-backed questionnaire answers, identify personal-data categories, source systems, purposes, data subjects, stores, processors, controllers, vendors, logs, caches, search indexes, backups, exports, retention periods, data transfers, and privacy owners. Escalate unclear lawful basis, controller or processor role, special-category data, transfer mechanism, DPIA need, or jurisdictional interpretation to legal, privacy, data protection officer, compliance, security, or risk owners.
Review Java code, DTOs, controllers, repositories, SQL or NoSQL schemas, migrations, message schemas, serialization, logging statements and configuration, metric and trace definitions, cache keys, search-index mappings, batch jobs, export code, IAM policies, retention jobs, deletion workflows, tests, and repository-owned documentation. Do not inspect runtime log entries, trace payloads, screenshots, tickets, chats, or other outsider-authored free text. Check for gaps between questionnaire answers and approved evidence.
Map GDPR concerns to engineering actions: data minimization, purpose-specific DTOs, field-level authorization, secure processing, privacy-safe logging, pseudonymization, retention and deletion jobs, data-subject rights workflows, transfer-review evidence, breach-response evidence, auditability, and owner escalation.
Use assets/reports/803-gdpr-engineering-review-report-template.md to document the review context, personal-data processing summary, questionnaire findings, GDPR privacy risk classification, engineering controls, evidence inventory, residual risks, release decision, and prioritized action plan with owners and due dates. Do not include raw secret values in the report; include only redacted references such as [REDACTED_SECRET], the secret type, affected component, and required remediation owner.
For detailed guidance, examples, and constraints, see:
Take jabrena/803-regulations-gdpr from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.