Add EU GDPR Pack (7 assistant workflows)

assistant-workflows/eu-gdpr-pack/contract-clause-checklist/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: "contract-clause-checklist"
+description: "Walk a single contract against 41 clause categories from the CUAD taxonomy and mark each one present, absent, or risky, quoting the clause when present, so that a safeguard the deal needs does not slip through by omission. Extractive: findings come from the contract text, not paraphrase. Use before signing, in negotiation, or in due diligence of one agreement, when the question is what is missing from this contract and which clauses bite. Jurisdiction-neutral framing with common-law roots; the assessment and the recommendation stay with the lawyer."
+license: "MIT"
+metadata:
+  version: "1.0.0"
+  author: "Wieslaw Mazur / MateMatic Solutions"
+  language: "English"
+  mike-display-name: "Contract Clause Checklist"
+  mike-type: "assistant"
+  mike-availability: "add-on"
+  practice: "General Transactions"
+  jurisdictions: "General"
+---
+# Contract Clause Checklist
+
+The most expensive clauses are the ones that are not in the contract. Reviewing a contract is not only reading what is written - it is checking that no safeguard the deal needs is absent. This workflow walks the contract against a fixed list of 41 clause categories and, for each, says: present, absent, or present-but-risky, quoting the clause when present.
+
+It is extractive - what it shows comes from the contract, not from paraphrase. It flags presence and risk; the assessment and the call stay with the lawyer.
+
+## The 41 categories (CUAD taxonomy)
+
+For each category: present / absent / risky, plus a quote when present.
+
+### Contract metadata
+- Document name, Parties (verify authority to sign), Governing law.
+
+### Group 1 - term and dates
+- Agreement date, Effective date, Expiration date, Renewal term (auto-renew?), Notice period to terminate renewal.
+
+### Group 2 - competition restrictions
+- Non-compete, Exclusivity, No-solicit of customers, Competitive restriction exception (carve-outs).
+
+### Group 3 - control and assignment
+- Change of control (consent or termination on M&A?), Anti-assignment.
+
+### Group 4 - licences
+- License grant, Non-transferable license, Affiliate license (licensor), Affiliate license (licensee), Unlimited license, Irrevocable or perpetual license.
+
+### Group 5 - post-term and audit
+- Post-termination services, Audit rights.
+
+### Group 6 - liability
+- Uncapped liability, Cap on liability.
+
+### Ungrouped
+- Most favored nation, No-solicit of employees, Non-disparagement, Termination for convenience, ROFR/ROFO/ROFN, Revenue/profit sharing, Price restrictions, Minimum commitment, Volume restriction, IP ownership assignment, Joint IP ownership, Source code escrow, Covenant not to sue, Liquidated damages, Warranty duration, Insurance, Third-party beneficiary.
+
+## Output format
+
+Start with the red flags, then the full table:
+
+- RED FLAGS: each absent category with why it is a risk in this deal, and each risky category with how it is one-sided.
+- 41-CATEGORY TABLE with columns: Category, Status, Note, Quote (if present).
+
+## Limits
+
+- This is a presence-and-risk checklist, not an interpretation of clause wording. Whether a clause is effective, and the recommendation, are the lawyer's.
+- The taxonomy is common-law-oriented at source; for a specific jurisdiction, add local-law anchors.
+- Descriptive references without a clause ("the parties intend to cooperate") have nothing to match - mark them as "no clause, manual check".
+
+## Attribution
+
+The 41-category clause taxonomy is based on CUAD (Contract Understanding Atticus Dataset), The Atticus Project, licensed CC BY 4.0 (https://www.atticusprojectai.org/cuad). Category descriptions and the risk framing are the author's own.

assistant-workflows/eu-gdpr-pack/gdpr-breach-notification/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: "gdpr-breach-notification"
+description: "Run the personal data breach decision tree under GDPR Articles 33-34 and EDPB Guidelines 9/2022: classify the breach, assess risk to rights and freedoms, track the 72-hour notification deadline from awareness, decide on communication to data subjects, and draft the supervisory authority notification, the data subject communication, and the internal register entry. Use when a data leak, ransomware incident, misdirected email, or lost device raises the question of whether and whom to notify. The workflow drafts; the controller or DPO decides and sends."
+license: "MIT"
+metadata:
+  version: "1.0.0"
+  author: "Wieslaw Mazur / MateMatic Solutions"
+  language: "English"
+  mike-display-name: "GDPR Breach Notification"
+  mike-type: "assistant"
+  mike-availability: "add-on"
+  practice: "Data Protection"
+  jurisdictions: "European Union"
+---
+# GDPR Breach Notification
+
+In a breach, the clock and the documented reasoning are what matter. This workflow runs a documented decision tree and produces drafts; the decision to notify and the act of sending belong to the controller or DPO. Do not guess - flag missing inputs for the risk assessment as gaps.
+
+## Step 1 - Is it a breach, and which type
+
+A personal data breach is a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data (Article 4(12)). Classify it as a confidentiality breach (disclosure or access), an integrity breach (alteration), or an availability breach (loss or destruction). Breaches are often combined - record every type that applies.
+
+## Step 2 - Risk assessment to rights and freedoms
+
+Assess against the factors in EDPB Guidelines 9/2022 (formerly WP250): type of breach; nature, sensitivity, and volume of the data; ease of identifying individuals; severity of consequences (identity theft, financial loss, discrimination, reputational harm); special characteristics of the individuals (children, patients); and the number of individuals affected. Record the outcome as one of three levels: no risk, risk, or high risk.
+
+## Step 3 - Notify the supervisory authority (Article 33) within 72 hours
+
+- The clock starts when the controller becomes aware of the breach, not when the incident occurred. The deadline is 72 hours from awareness. Compute the exact deadline date and time and state it in the draft and the register - do not estimate it.
+- Notification is required unless the breach is unlikely to result in a risk to rights and freedoms (Article 33(1)). If not notifying, justify and document the decision.
+- If the deadline has passed, notify anyway and state the reasons for the delay (Article 33(1), second sentence).
+- Draft the notification to the content required by Article 33(3): nature of the breach with categories and approximate numbers of data subjects and records, DPO contact details, likely consequences, and measures taken or proposed. Notification in phases is allowed (Article 33(4)).
+
+## Step 4 - Communicate to data subjects (Article 34)
+
+If the risk is high, the controller must communicate the breach to the affected individuals without undue delay, in clear and plain language, covering the elements of Article 34(2): description of the breach, DPO contact, likely consequences, and measures. Check the exemptions in Article 34(3): safeguards that render the data unintelligible (such as encryption), subsequent measures that eliminate the high risk, or disproportionate effort - in which case draft a public communication instead.
+
+## Step 5 - Breach register (Article 33(5))
+
+Record every breach in the internal register, including breaches that were not notified: facts, effects, and remedial action. The register is the accountability evidence the supervisory authority will ask for.
+
+## Governance boundary
+
+The workflow runs the decision tree, tracks the 72-hour deadline, and drafts the notification, the data subject communication, and the register entry. A human approves the risk assessment and sends the notification and communications. Sending is never automatic.

assistant-workflows/eu-gdpr-pack/gdpr-data-subject-requests/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: "gdpr-data-subject-requests"
+description: "Handle a data subject rights request under GDPR Articles 12 and 15-22: identify the right invoked (access, rectification, erasure, restriction, portability, objection, automated decisions), verify identity, track the one-month deadline and the two-month extension, check exemptions and refusal grounds, and draft the response plus a request register entry. Use when a subject access request, erasure request, objection, or portability request arrives and the deadline and legal gates must be worked through. The workflow drafts; a human decides, performs the erasure or export, and sends the response."
+license: "MIT"
+metadata:
+  version: "1.0.0"
+  author: "Wieslaw Mazur / MateMatic Solutions"
+  language: "English"
+  mike-display-name: "GDPR Data Subject Requests"
+  mike-type: "assistant"
+  mike-availability: "add-on"
+  practice: "Data Protection"
+  jurisdictions: "European Union"
+---
+# GDPR Data Subject Requests
+
+A rights request is a clock plus a legal assessment, not an automation. The workflow classifies the request, tracks the deadline, and produces a draft; the fulfil-or-refuse decision and the act of sending belong to the controller. Erasure and export are irreversible or outward acts, so they always stay with a human.
+
+## Step 0 - Identity and deadline
+
+- Identity verification (Article 12(6)): where reasonable doubt exists, request further information. This pauses the clock until identity is confirmed, but must not be used to obstruct the request.
+- Deadline: one month from receipt (Article 12(3)), extendable by up to two further months for complexity or number of requests - the data subject must be informed of the extension and its reasons within the first month. Compute the exact deadline dates and state them in the draft and register. Month arithmetic has traps: under Regulation (EEC) No 1182/71, a request received on 31 January runs to the last day of February.
+- Free of charge by default (Article 12(5)). A fee or refusal is allowed only where the request is manifestly unfounded or excessive, and the burden of proof is on the controller.
+
+## Step 1 - Classify the right
+
+| Article | Right | Key points |
+|---|---|---|
+| 15 | Access and copy | scope of information, copy of the data, third-party rights |
+| 16 | Rectification | inaccurate or incomplete data |
+| 17 | Erasure ("right to be forgotten") | grounds in 17(1) against the exemptions in 17(3): legal obligation, legal claims, freedom of expression |
+| 18 | Restriction | a freeze instead of erasure |
+| 20 | Portability | consent or contract basis plus automated processing only; structured, machine-readable format |
+| 21 | Objection | legitimate interest or direct marketing - the marketing objection is absolute |
+| 22 | Automated decisions | right to human intervention |
+
+A request can be informal - interpret its substance, not its heading.
+
+## Step 2 - Gates and refusal grounds
+
+Check the exemptions specific to the right invoked (especially Article 17(3) and national restrictions). Every refusal must be legally justified and must inform the data subject of the right to lodge a complaint with the supervisory authority and to seek a judicial remedy (Article 12(4)).
+
+## Step 3 - Draft the response and the register entry
+
+Draft the response in clear and plain language (Article 12(1)), a list of the data and its sources drawn from the records of processing, and a register entry recording receipt date, request type, deadline, and outcome.
+
+## Governance boundary
+
+The workflow classifies, computes deadlines, drafts, and maintains the register. A human verifies identity, decides whether to fulfil or refuse, performs the erasure or export, and sends the response. Irreversible and outward acts are never automatic.

assistant-workflows/eu-gdpr-pack/gdpr-dpia/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: "gdpr-dpia"
+description: "Assess whether a Data Protection Impact Assessment is required under GDPR Article 35 and draft it to the Article 35(7) structure: run the threshold test against the EDPB WP248 criteria, the Article 35(3) mandatory cases, and the national supervisory authority blacklist, then build the systematic description, the necessity and proportionality assessment, the risk assessment, and the mitigating measures, and decide whether Article 36 prior consultation applies. Use for profiling, CCTV, AI systems, large-scale monitoring, or any processing that may be high risk. The workflow drafts; the controller accepts residual risk and files."
+license: "MIT"
+metadata:
+  version: "1.0.0"
+  author: "Wieslaw Mazur / MateMatic Solutions"
+  language: "English"
+  mike-display-name: "GDPR DPIA"
+  mike-type: "assistant"
+  mike-availability: "add-on"
+  practice: "Data Protection"
+  jurisdictions: "European Union"
+---
+# GDPR DPIA
+
+A DPIA is not a checkbox - it is a process for managing risk to the rights and freedoms of natural persons. This workflow runs the process and produces a draft; the residual-risk acceptance and the go/no-go decision belong to the controller.
+
+## Step 1 - Is a DPIA required (Article 35(1) threshold)
+
+A DPIA is mandatory where processing is likely to result in a high risk. Check three routes:
+
+1. The supervisory authority's mandatory list (Article 35(4)) - each EU supervisory authority publishes a list of operations that always require a DPIA. Check the relevant national list.
+2. The nine EDPB criteria (WP248 rev.01), with the rule of thumb that meeting two or more criteria means a DPIA is required: evaluation or scoring; automated decisions with significant effect (Article 22); systematic monitoring; sensitive or highly personal data; large-scale processing; matching or combining datasets; vulnerable data subjects (children, employees); innovative technology (AI, IoT); and processing that prevents exercising a right or using a service.
+3. The explicit cases in Article 35(3): systematic and extensive evaluation including profiling, large-scale processing of special-category or criminal data, and large-scale systematic monitoring of publicly accessible areas.
+
+Record the verdict as required, recommended, or not required, with a per-criterion justification. This is a screening, not a clearance - the controller documents the decision.
+
+## Step 2 - DPIA structure (Article 35(7) minimum)
+
+Draft the four pillars:
+
+- (a) A systematic description of the processing and its purposes, including the legitimate interest where relied on.
+- (b) An assessment of necessity and proportionality against the purposes: minimisation, legal basis, purpose limitation, retention, data subject rights, transfers.
+- (c) A risk assessment to rights and freedoms: risk sources, confidentiality, integrity, and availability scenarios, likelihood times severity.
+- (d) The measures envisaged to address the risks and demonstrate compliance, plus the residual risk.
+
+Record the DPO's advice (Article 35(2)) and any consultation with data subjects (Article 35(9)).
+
+## Step 3 - Prior consultation (Article 36)
+
+If the residual risk remains high despite the measures, the controller must consult the supervisory authority before processing. Draft the consultation request to the scope of Article 36(3) - a human files it.
+
+## Governance boundary
+
+The workflow classifies the criteria, drafts the DPIA, and prepares the consultation request. A human approves the risk assessment, decides on deployment, signs, and files. The outward act of filing with the supervisory authority is never automatic.

assistant-workflows/eu-gdpr-pack/gdpr-records-of-processing/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: "gdpr-records-of-processing"
+description: "Build and validate the records of processing activities (RoPA) required by GDPR Article 30: the controller register under Article 30(1) and the processor register under Article 30(2), enforcing every mandatory field - purposes, categories of data subjects and data, recipients, third-country transfers and safeguards, erasure time limits, and security measures. Flags activities that trigger a DPIA and tests the narrow Article 30(5) exemption. Use when creating a RoPA from scratch, auditing an existing register for gaps, or preparing accountability evidence for a supervisory authority. Complements the DPA review workflows, which cover the processor contract itself."
+license: "MIT"
+metadata:
+  version: "1.0.0"
+  author: "Wieslaw Mazur / MateMatic Solutions"
+  language: "English"
+  mike-display-name: "GDPR Records of Processing"
+  mike-type: "assistant"
+  mike-availability: "add-on"
+  practice: "Data Protection"
+  jurisdictions: "European Union"
+---
+# GDPR Records of Processing
+
+The RoPA is a living accountability document, and its required content can be checked mechanically against Article 30. This workflow builds or validates the register and reports gaps; ownership of the register and every filing decision stay with the controller.
+
+## Controller register (Article 30(1))
+
+For each processing activity, the register must record:
+
+- the name and contact details of the controller, any joint controller, the representative, and the DPO,
+- the purposes of the processing,
+- the categories of data subjects and the categories of personal data,
+- the categories of recipients, including recipients in third countries or international organisations,
+- transfers to third countries with the identification of the country and the documentation of safeguards (Chapter V),
+- the envisaged erasure time limits for each category of data,
+- a general description of the technical and organisational security measures (Article 32).
+
+Validate completeness field by field. A missing field is a gap to report, not a value to guess.
+
+## Processor register (Article 30(2))
+
+The processor's register is narrower: the categories of processing carried out on behalf of each controller, transfers with safeguards, and a general description of security measures. Record the controllers and any sub-processors by name.
+
+## Cross-checks
+
+- Flag every activity whose description meets a DPIA trigger (profiling, large-scale special-category data, systematic monitoring) so it can be taken through a DPIA.
+- Test the Article 30(5) exemption honestly: it applies only to organisations under 250 employees whose processing is occasional, low-risk, and involves no special categories. In practice it rarely applies - most organisations process employee or customer data regularly.
+- Where the register reveals a processor without a compliant processing contract, note it and route the contract itself to a DPA review workflow.
+
+## Output
+
+A draft register (or a gap report against an existing one) with each activity marked complete or listing its missing fields, plus the DPIA flags and contract flags.
+
+## Governance boundary
+
+The workflow builds and validates the register and maps gaps to the article. A human approves the content and owns the register. Nothing is filed or signed automatically.