Comply

comply: legal is a gate, not a vibe

docs/compliance/COMPLIANCE.md holds the regimes and when they bite, the same in every project. docs/compliance/REGISTER.md is this project's register: which of them apply here, status per obligation, evidence per row. This skill fills and re-verifies both.

1. Determine what applies (per project, honestly)

Walk that trigger table against BRIEF.md and the actual system: personal data? (almost always yes: an email address is enough) → GDPR/AVG. AI features → AI Act, at minimum Art 50 transparency. Consumer-facing digital service/e-commerce → European Accessibility Act. Product with digital elements sold in the EU → CRA. Software placed on the EU market, which is virtually every shipped product → Product Liability Directive. Essential/important sector or supplier to one → NIS2. The client is a financial entity → DORA. Connected product, or a cloud/SaaS service a customer can switch away from → Data Act. Every dependency → its license. The organization has rules on AI tooling (a regulated sector, government, confidential data, or a client that asks) → docs/operations/agent-security.md is filled before the first session on their data: where prompts go, what the agent can reach, who can stop it, what is kept.

2. Verify current state of the law

Regulations shift (every regime row carries its own last-verified date; they age). For each applicable regime, confirm today's status via authoritative sources (EUR-Lex, the Commission's pages, the AP (autoriteitpersoonsgegevens.nl) for NL) and update the dates in the regimes table. Stamp today in Dates verified on the rows you actually checked, and leave the other rows' stamps alone: a partial pass that stamps the whole table turns a stale row into a fresh-looking one. Never assert a deadline or obligation from model memory. Deadline horizon: when any date there falls within the next 60 days, re-verify that regime now instead of waiting for the quarterly audit - rules move fastest just before they bite. No network in this environment: the row keeps its old stamp and reads open (unverified) with the source it would check, never n/a.

3. Apply per obligation: build it in, don't bolt it on

• GDPR/AVG: lawful basis named per processing purpose; data minimization in the schema (collect nothing "for later"); records of processing (Art 30); the DPIA screened against the AP's list and the EDPB criteria and the outcome recorded as a register row, a negative one included (Art 35); a privacy notice at the point of collection (Art 13 and 14); cookies and similar storage only with consent where the Telecommunicatiewet asks it, verified at use time; data-subject rights executable (export, delete: actually implemented, not promised); the retention periods recorded here honored to the end, the product's own retirement included (maintain owns that step); processor agreements for every third-party service touching personal data; EU data residency checked per service; breach path known (72h to the AP).
• AI Act: users told they're interacting with AI; AI-generated content marked machine-readably (Art 50, binding from 2026-08-02); high-risk uses (Annex III) identified early. Obligations land 2027-12-02, design for them now, not then. Art 4 AI literacy: docs/compliance/AI-LITERACY.md is the evidence note; keep the register's literacy line true for this team and re-check the note at the quarterly audit.
• Accessibility: the level docs/compliance/COMPLIANCE.md names for new interfaces (EN 301
  549. as the working floor. Evidence: the renders scan in the stack's floor table and design-guard per delivery; this skill checks the claim holds product-wide, and where the EAA applies an accessibility statement is published with the product.
• CRA: scope before duties, because both the CRA and the PLD turn on the same test: supply in the course of a commercial activity. Free and open-source software its maintainer does not monetise is outside it, and paid services alongside a freely downloadable product or donations that do not gate access do not change that; a paid edition, updates behind a payment, or other services monetised through it do. A legal person sustaining such an unmarketed project intended for commercial use is an open-source software steward instead (Art 24). Inside scope: secure-by-default posture, and the vulnerability intake channel plus the support period published in the root SECURITY.md (ships as a working template; fill its marked TBD fields); actively exploited vulnerability → reporting duty via ENISA platform (from 2026-09-11). The regimes table's CRA row carries that scope test in full: settle it before writing a duty.
• PLD: software is a product with no-fault liability; defectiveness includes cybersecurity vulnerabilities, and damage covers users' destroyed or corrupted data. The CRA posture above plus a proven restore path (docs/operations/backup-restore.md) are the working defense.
• DORA: the obligations arrive through the financial client's contract (Art 30: security measures, incident support, audit and access rights, exit strategy); check those clauses against what the product actually delivers and record any gap in the register.
• Data Act: a connected product is designed so its data reaches the user by default, not bolted on as an export later; a cloud/SaaS offering carries no switching barriers and an exit the customer can actually walk, contract terms and egress included.
• Licensing: every dependency's license compatible with the product's use and distribution; copyleft obligations honored; the register lists anything non-trivial.

4. Verdict and record

Register updated: per obligation met / open / blocked / n/a + evidence link. Open items that block delivery are named as blockers in STATE.md. Delivery waits, that's the point. Report: what applies, what's green, what blocks, the one next step. ⚓