Audit croatian gdpr compliance skill

<objective> Audit a product idea, build, launch, or live system against GDPR product-creation duties, then apply Croatia-specific data protection law check-up gates where Croatia is in scope.

The audit must produce evidence-backed findings: what was checked, what passed, what failed, what is not applicable, and what needs legal confirmation. Do not present this as legal advice. </objective>

<quick_start> A full audit runs as an orchestrated pipeline: you (the orchestrator) scope inline, fan out parallel domain agents that each read their own checklist file and return findings, synthesize inline, optionally verify sources with parallel agents, then write the HTML report. This is heavier than a single-pass read; that is the point. See <workflow> for the phases and <subagent_guardrails> for the cost/fan-out rules.

For every Croatian GDPR compliance audit:

1. Ask the intake questions unless the user already gave the answer.
2. Establish Croatia nexus (yes / unknown / no) before deciding which agents to spawn.
3. MANDATORY - READ ENTIRE FILE: references/current-source-register.md yourself before any final or client-facing legal-source claim (the orchestrator still owns source decisions).
4. The per-domain checklist files are read IN FULL by the domain agents, not by you: references/product-creation-checklist.md (GDPR baseline + overlays) and references/source-and-checklist.md (Croatian overlay, only when Croatia nexus is yes/unknown). For the inline fast-pass exception you read them yourself.
5. Do NOT load templates/audit-report.html unless producing a written deliverable.
6. Do NOT load references/example-saas-audit.md unless calibrating severity, handling unknown, or separating EU baseline from Croatian overlay is unclear. </quick_start>

<intake> Ask only the questions whose answers are missing. If the user wants a fast first pass, proceed with `unknown` answers and mark the uncertainty in the report.

1. What are we reviewing: SaaS/web app, mobile app, website/cookies, AI/ML feature, e-commerce/account creation, API/platform, connected physical product/IoT device, workplace tool, video/biometric system, medical/health product, or something else?
2. What stage is it in: idea/spec, design, implementation, pre-launch, live audit, or incident/remediation?
3. Who are the data subjects: consumers, B2B users, employees, children, patients, building residents/visitors, public-area passers-by, or mixed groups?
4. What personal data is processed: identifiers/contact, payment, location, device telemetry, behavioral analytics, content/messages, special-category data, health, biometrics, genetic data, video/audio, or children data?
5. What is the Croatia/EU nexus: Croatian company, services offered in Croatia, Croatian users/residents, Croatian workplace/building/public area, EU users only, or non-EU with EU monitoring/offering?
6. What role and ecosystem exist: controller, processor, joint controller, Article 27 EU representative, EU main establishment/lead authority, sub-processors/vendors, public authority/public service, or unclear?
7. What evidence is available: product spec, UI/screens, code, data map/RoPA, DPIA, privacy notice, consent records, retention config, processor DPAs, logs, policies, or none?
8. Which regulated overlays may apply: automated decision-making/profiling, research/statistics/archiving, criminal-offence data, healthcare system/data, public electronic communications service, website cookies/local storage, electronic marketing, cybersecurity/NIS2-like essential or important entity, video surveillance, workplace/residential/public-area monitoring, or none/unknown? </intake>

<workflow> The orchestrator (you, in the main skill context) owns scoping, synthesis, and report assembly. Subagents own the per-domain audit and the source verification. Spawn each parallel batch as multiple `Agent` tool calls in a SINGLE message so they run concurrently. Use the built-in `general-purpose` agent type; this skill needs no other agent.

Phase 0 — Scope (inline, you)

• Run intake. Classify product surface, stage, data subjects, data classes, legal role, vendors, EU/Croatia nexus, and high-risk triggers using the <decision_tree> in product-creation-checklist.md.
• Establish Croatia nexus: yes, unknown, or no. This decides whether the Croatian overlay agent is spawned.
• Decide the in-scope domains and therefore which agents to spawn (see Phase 1). Group related product-type overlays so you stay under the fan-out cap.
• Build a one-paragraph shared evidence pack: product description, the artifacts available for inspection (code, UI, privacy notice, data map, consent flows, retention config, DPAs, logs, etc.), and the scope classification. Every domain agent receives this verbatim.
• Completion criterion: every intake field is answered or explicitly marked unknown; Croatia nexus is explicit; the list of agents to spawn is fixed.
• Inline fast-pass exception: if the scope is a single domain with no Croatia nexus AND the user asked for a quick pass, skip Phases 1-2, read the relevant checklist file yourself, audit inline, and state in the output that the fast path was used.

Phase 1 — Parallel domain audit agents (spawn in ONE message) Spawn one general-purpose agent per in-scope domain, capped at ~3-6 total:

1. GDPR baseline auditor (always) — instructed to READ THE ENTIRE FILE references/product-creation-checklist.md, then apply <baseline_checklist>, <decision_tree>, and <expert_tradeoffs>.
2. Croatian overlay auditor (only when Croatia nexus is yes/unknown) — instructed to READ THE ENTIRE FILE references/source-and-checklist.md, then apply <scope_gates>, <checklist>, and <evidence_rules>.
3. Product-type overlay auditor(s) — one per selected overlay cluster from <product_type_overlays> (e.g. AI/ML + automated decisioning; cookies + electronic marketing; workplace + video/biometric; health/special-category; IoT; e-commerce). Group related overlays to stay under the cap; the relevant file to read in full is references/product-creation-checklist.md (and references/source-and-checklist.md for Croatian video/biometric/health gates when Croatia is in scope).

Each agent prompt MUST include, verbatim: the shared evidence pack; the explicit instruction to read its assigned reference file IN FULL before any verdict; and this fixed return schema, one row per gate: gate | verdict (pass / fail / risk / not applicable / needs legal confirmation) | severity (Blocker / High / Medium / Low) | evidence cited (observed artifact, missing artifact, or stated assumption) | article or source reference | remediation. Tell the agent: inspect real evidence only; mark unknown when evidence is missing and never infer compliance from silence; cite article numbers (and sector source names for cookies/marketing/healthcare/cybersecurity); keep the response to the schema rows plus a 2-line summary.

When all agents return: post a 2-3 line chat note (top blockers + biggest evidence gap). Keep the raw findings tables out of chat — they feed Phase 2.

• Completion criterion: every in-scope baseline gate, Croatian gate, and selected product-type overlay has a verdict and remediation path from an agent.

Phase 2 — Synthesize (inline, you)

• Merge the agent findings, dedupe overlapping gates (e.g. cookies appears in baseline and Croatian overlay — keep the stricter verdict and note both bases), and rank by severity, blockers first.
• Keep the EU GDPR baseline verdict and the Croatian implementation-act verdict separate; do not merge them into one score.
• Split engineering fixes from legal-confirmation questions.
• Completion criterion: a single ranked findings set with no duplicates and a clear baseline-vs-Croatian split.

Phase 3 — Source verification agents (parallel, spawn in ONE message) — high-stakes/client-facing/final only

• For draft triage, skip this phase and mark every legal conclusion preliminary (per <refresh_rules> in the source register). Otherwise:
• First read references/current-source-register.md yourself to pick the source clusters that back the actual findings.
• Spawn general-purpose agents, one per sector source cluster from <official_source_anchors> (~3-5: e.g. GDPR core EUR-Lex; AZOP + Croatian implementation act NN 42/18; healthcare NN 14/2019; HAKOM cookies/electronic communications; cybersecurity NKS). Each fetches the official current source, confirms or corrects the legal basis used in the relevant findings, and returns: source name, URL, retrieved-on date, source type, current enough for conclusion (yes / no / preliminary / needs legal confirmation), and any conflict vs the DLA Piper PDF.
• Apply corrections to the findings: fix wrong article numbers/wording, downgrade conclusions where the source could not be confirmed, and flag conflicts as needs legal confirmation.
• Completion criterion: every legal source used in the report has a URL or local path, retrieval date, and freshness status.

Phase 4 — Report (inline, you)

• Use templates/audit-report.html unless the user explicitly asks for another format. Clone it; keep the CSS verbatim.
• Fill every section (Executive Verdict, Scope, Findings, Coverage, Sources Checked, Evidence Reviewed, Next Actions). Lead with blockers and high-risk issues. Keep legal-confirmation questions separate from engineering fixes.
• Write a standalone .html with inline CSS/JS (no external assets), open it with the platform opener (macOS open, Linux xdg-open, Windows start ""), and give the absolute file path.
• Deliver in chat: file path, overall verdict, blocker count, and the source/freshness tally.
• Completion criterion: the HTML opens locally without external assets and lets the reader scan verdict, blockers, findings, sources, evidence, and next actions without re-running the audit. </workflow>

<subagent_guardrails>

• Cost. A full audit spawns ~3-6 domain agents plus ~3-5 source-verifier agents. That is expected. Do NOT fan out wider than the in-scope domains; group product-type overlays into one agent rather than adding agents.
• Read discipline lives in the agents. Each domain agent MUST read its assigned reference file in full before any verdict. The orchestrator no longer reads every checklist file itself, but still reads references/current-source-register.md for scope and source decisions, and reads the checklist files itself only on the inline fast-pass.
• Self-contained. Built-in tools only: Agent with general-purpose, Read, Write, and the web fetch/search the agents use inside Phase 3. No external scripts, APIs, or other skills. Drop the folder into any .claude/skills/ directory and it works.
• Keep raw agent output out of chat. The orchestrator posts only the Phase 1 convergence note and the Phase 4 delivery summary; findings live in the report.
• Real evidence only. No invented artifacts, article numbers, or sources. Missing evidence is unknown/risk, never pass. The skill does not provide legal advice. </subagent_guardrails>

<source_policy> This skill was created from the user's Croatian data protection source material and upgraded on 2026-06-30 using the local PDF:

• /Users/juresunic/Downloads/DLA-Piper-Data-Protection-Laws-of-the-World-Croatia.pdf

The PDF is a secondary legal map, marked "LAST MODIFIED 10 FEBRUARY 2026". Current official source anchors are listed in references/current-source-register.md.

This skill was also upgraded on 2026-06-30 with the user's Croatian-language GDPR attachment as an official-text cross-check for EU baseline gates and Croatian terminology.

For high-stakes legal conclusions, refresh the current Croatian and EU sources before finalizing the audit. If the current law differs from this checklist or the DLA Piper PDF, cite the current law and update the finding. </source_policy>

<reference_guides>

• references/current-source-register.md - Source hierarchy, official links, DLA Piper PDF scope, and refresh rules.
• references/product-creation-checklist.md - EU GDPR product-creation baseline and product-type overlays.
• references/source-and-checklist.md - Croatia-specific audit gates, DLA Piper Croatia law-map coverage, and article/source mapping.
• references/example-saas-audit.md - short filled example for severity and unknown calibration; load only when needed.
• templates/audit-report.html - Standalone interactive report shell for product, SaaS, and feature audits. </reference_guides>

<success_criteria> The skill has worked when:

• Croatia nexus is explicit.
• Product type, stage, data subjects, data categories, controller/processor role, and evidence level are explicit.
• Source freshness is explicit for the DLA Piper PDF and current official sources used.
• GDPR product-creation baseline status is stated.
• Every Croatia-specific gate is pass, fail, risk, not applicable, or needs legal confirmation.
• Every selected product-type overlay is pass, fail, risk, not applicable, or needs legal confirmation.
• Findings cite product evidence and article references.
• High-stakes reports include source URLs and retrieval dates.
• Healthcare, cookies/electronic communications, electronic marketing, DPO notification, breach, transfer, Article 22 automated-decision, Article 26 joint-controller, Article 27 representative, Article 89 research/statistics/archiving, and cybersecurity-adjacent gates are considered when triggered by the intake.
• Engineering fixes are separated from counsel/legal interpretation questions.
• Written deliverables are standalone HTML files unless the user explicitly asks for another format.
• The final report does not imply legal advice or current-law certainty without source verification. </success_criteria>