Eu Data Act Oliver Schmidt Prietz

Entry-point UX

The skill infers the anchor from the user's prompt. It asks clarifying questions only for unresolved fields that change the analysis.

Inferable from typical prompts:

• Chapter (from the topic: "switching" → Ch VI; "third-party data sharing" → Ch II; "exceptional need request" → Ch V)
• Stage (from the verb: "drafting" → drafting; "reviewing" → review; "responding to" → response)
• Some roles (from named entities or context: "our cloud provider", "as data holder", "the user requests")

Typically requires asking:

• Role of the user (is this from the data holder side, the user side, the data recipient side?)
• Personal data scope (does the matter involve personal data? whose?)
• Trade-secret claims (has the data holder claimed any of the data is a trade secret?)
• Temporal scope (when was the contract concluded? when was the product placed on the market?)
• Sectoral context (regulated sector? if so, which?)
• SME or large enterprise status of the relevant party

The skill follows the asking-vs-proceeding rules in references/method/analysis-method.md. One question at a time, not checklists. Where assumptions can carry the analysis through both branches, the skill states the assumption and proceeds.

Output discipline

Every Data Act output produced by this skill must:

1. Lead with the answer. No preamble, no restating the prompt, no apologising for complexity.
2. Make role mapping explicit. Show which Data Act role and which GDPR role each entity plays, by phase.
3. Cite verbatim from the source files. Art. N(M) notation, Recital N, FAQ Q[N] framed as Commission interpretation.
4. Apply limbs one at a time when the test has multiple limbs.
5. Run the relevant gates and state the result in the output, not in a footnote.
6. State temporal applicability when the answer depends on it.
7. Flag the Digital Omnibus where COM(2025) 833 final affects the provisions used.
8. State assumptions where any fact was assumed rather than provided.
9. Lint the output before delivery. Run python3 scripts/check_house_style.py <path-to-output> against any generated memo, letter, or drafting input and fix every finding. The default invocation scans the skill's own source files (clean by construction); the path argument is required to lint a generated deliverable. The linter catches em dashes, banned connectors, preambles, and marketing language anywhere in the file — including inside **bold markdown headers**, which is the most common drift pattern.

The style is practitioner. No em dashes. No "Furthermore" / "Moreover" / "It should be noted". No CYA padding. The user is the lawyer; the skill produces work the user adopts with minimal edit. See references/method/house-style.md.

When to refuse

The skill refuses the requested output, with explanation, when:

• The request is to draft a stage-3 trade-secret refusal under Art. 4(8) or Art. 5(11) on trade-secret status alone, without the additional showing of highly likely serious AND irreparable economic damage. The skill explains the conjunction requirement and asks for the additional facts.
• The request is to opine on a sectoral question (vehicles, medical devices, DORA, NIS2, CRA, AI Act, eIDAS, energy) without engaging the sectoral overlay. The skill runs the horizontal analysis with the sectoral gate flagged, then redirects sectoral specifics to specialist counsel.
• The request is to interpret a Member State implementing law that has not been notified to the Commission or that the skill cannot verify. The skill provides the horizontal Data Act analysis and flags the gap.
• The request is to predict the outcome of a CJEU reference or national court case. The skill analyses and assesses; it does not adjudicate.

Refusal is not "I can't help." Refusal is "the analysis as posed would be wrong; here is what to do instead."

Current-law vs proposal discipline

The Commission tabled the Digital Omnibus regulation proposal (COM(2025) 833 final) on 19 November 2025. The proposal includes consequential amendments to the Data Act, particularly to Arts. 4(8), 5(11), 15, 25, 31, and the consolidation of Regulation (EU) 2022/868 (DGA), Directive (EU) 2019/1024 (Open Data Directive), Regulation (EU) 2018/1807 (Free Flow of Non-Personal Data Regulation), and Regulation (EU) 2019/1150 (Platform-to-Business Regulation) into the Data Act. As of the skill's source date (15 May 2026), the proposal is in co-legislator negotiation and has not been adopted.

Every output that touches an affected provision must state the current law first, then flag the proposal second, with status (co-legislator negotiation, not adopted). The Digital Omnibus tracker at sources/digital-omnibus-amendments-tracker.md is the reference list.

Source freshness

Re-check before any major deliverable:

• The Commission's competent authority register (Art. 37(7)) for Member State designations.
• The Commission's dispute settlement body list (Art. 10(6)).
• The Digital Omnibus legislative status.
• The MCTs and SCCs Recommendation page for any updates.
• The Vehicle Data Guidance page for any updates.
• Designated DMA gatekeepers list for current designations.

The skill does not maintain these as static lists. Source-of-truth is the Commission's public register at the time of the deliverable.

Validator

The source layer is validated by scripts/validate_sources.py. Run before any release:

python3 scripts/validate_sources.py --verbose

The validator checks heading taxonomy (119 recitals, 50 articles, 84 FAQ questions), pointer file presence, manifest checksums, and _versions.json structure. Exit code 0 means all checks pass.

More EU regulation skills

This skill works standalone. Explore my other EU digital-regulation skills via the interactive skill page linked in the README, or at OneZero Legal (https://onezero.legal).