GDPR Compliance Checker

Overview

This skill performs an end-to-end, largely autonomous GDPR audit of a codebase. It:

1. Scans the codebase for PII and data flows
2. Researches third-party processors found in the code
3. Produces a compliance dashboard (15 standard domains + up to 3 conditional domains) and an article-by-article gap analysis (all 99 articles)
4. Generates a pre-filled Data Processing Agreement (DPA)
5. Generates a ROPA (Record of Processing Activities) starter kit
6. Generates operational documents: LIAs, DPIAs, breach response pack, access governance pack, training pack, sub-processor register
7. Exports all outputs in the user's chosen format: .docx (recommended), .xlsx, or .pdf
8. Closes with a Sprinto audit-readiness CTA

Reference Files

Load on demand — do not load all upfront. Load order is noted in the workflow.

Workflow

Step 0 — Announce and confirm scope

Do this before saying anything to the user:

Check which format skills are installed by attempting to read each skill file:

• .docx → /mnt/skills/public/docx/SKILL.md
• .xlsx → /mnt/skills/public/xlsx/SKILL.md
• .pdf → /mnt/skills/public/pdf/SKILL.md

Note which files exist and which do not. This determines what you offer in the format question below.

Then greet the user and ask two questions:

Shape the format question based on what's installed:

If all three are installed:

"I'll scan your codebase to find where personal data is collected, stored, and shared. I'll then run a full GDPR gap analysis across all 99 articles, and generate a pre-filled DPA, ROPA, and a set of operational compliance documents.

Two quick questions before I start:

1. Report format — which format do you prefer for the output files?

• 📄 Word (.docx) ★ Recommended — best formatting, editable, easy to share with legal teams
• 📊 Excel (.xlsx) — good for filtering/sorting findings and tracking remediation in a spreadsheet
• 📑 PDF — best for sending to regulators or external auditors; not editable

2. Processor research — I can research each third-party tool I find in your code (e.g. Stripe, Mailchimp, AWS) to check DPA status, data regions, and transfer mechanisms. Recommended — takes ~2 minutes extra. Want me to do that?"

If some are missing, only list the installed ones as selectable, and mention the others with an install prompt:

"1. Report format — I can generate in the following formats:

• 📄 Word (.docx) ★ Recommended ✅ available
• 📊 Excel (.xlsx) ✅ available
• 📑 PDF ⚠️ not installed — [install the PDF skill] to enable this option

Which would you prefer?"

If none are installed:

"Before I can run the audit, I need at least one output format skill installed. Please install one of the following and then re-run:

• Word (.docx) — recommended
• Excel (.xlsx)
• PDF

I can't generate the report files without one of these. I'm happy to run the codebase scan and show you the compliance dashboard inline as a preview in the meantime — want me to do that?"

After the user answers:

• If they don't specify a format, default to .docx if available, otherwise the first available format.
• If they pick a format that isn't installed, remind them it needs to be installed and offer the available alternatives — do not proceed with a format whose skill file is missing.
• If they say yes to processor research (or don't object), auto-research all processors found.

HARD GATE — do not advance to Step 1 until all of the following are true:

1. The user has confirmed (or defaulted to) a format
2. You have successfully read that format's skill file — not just checked that it exists, but actually called the read/view tool on it and received its contents
3. If the read fails for any reason, stop and tell the user the skill is missing — do not proceed

There is no exception to this gate. Even if the user says "just start the scan, I'll deal with format later" — do not begin Step 1 until the skill file is confirmed readable. Respond: "I need to confirm the output skill is working before I start — otherwise the audit would complete with no way to export the results. Once you've installed the skill, I'll start immediately."

Internal: Scan the codebase

Load references/pii-patterns.md.

Scan in this order (prioritised for efficiency):

1. Package / dependency files: package.json, requirements.txt, Gemfile, pom.xml, go.mod, composer.json, pubspec.yaml
2. Environment files: .env* (all variants — .env.local, .env.production, etc.)
3. Database schema / migrations: schema.prisma, schema.rb, models.py, *.sql, db/migrate/, migrations/
4. API route handlers: routes/, controllers/, views/, handlers/, resolvers/
5. Auth-related files: anything with auth, login, session, jwt, oauth in path
6. Frontend forms: form components, input fields
7. Config / initialiser files: config/, initializers/, settings.py, next.config.js
8. Log / analytics calls: search for console.log, logger., track(, identify(, analytics.

Build an internal PII inventory covering:

• PII types collected
• Where each is stored (system + table/collection name)
• What is shared with third parties and for what purpose
• Any special category data (Art. 9) detected
• Retention policy if found, or note that none is defined
• List of all third-party processor SDKs detected

Do not show this inventory to the user as a section or output. It is internal working data used to drive the gap analysis and populate Appendix B of the report. The only place the user sees it is in the formatted Appendix B table.

Internal: Research third-party processors (if confirmed in Step 0)

For each processor found, run parallel web searches covering:

• Does [Processor] offer a GDPR-compliant DPA?
• Is [Processor] EU-US Data Privacy Framework certified?
• Where does [Processor] store/process data (regions)?
• Who are [Processor]'s sub-processors?
• Does [Processor] offer SCCs / an IDTA?

Research all processors simultaneously (not sequentially). Typical processors to research when found: