| name | generate-gdpr-ropa |
| description | Generates a draft GDPR Article 30 Record of Processing Activities (ROPA) from MODULE_MANIFEST.md and BEHAVIORAL_CONTRACTS.md context files. Use when preparing for a GDPR audit, when a dark-code-audit flags PII-handling services with incomplete documentation, or when building a compliance package. Reads context layers across the codebase, groups them into logical processing activities, auto-populates what it can, and interviews the user for fields that require human judgment (legal basis, purpose, international transfers). Writes docs/compliance/gdpr-ropa-YYYY-MM-DD.md. Invoke as /generate-gdpr-ropa or /generate-gdpr-ropa --module path/to/module for a single module entry.
|
/generate-gdpr-ropa
Generates a draft GDPR Article 30 ROPA from code context files. The output is a draft — it requires legal review before use as a compliance document. Your job is to make that review fast by capturing everything that can be derived from the code without asking a lawyer.
What you're doing and why
MODULE_MANIFEST.md and BEHAVIORAL_CONTRACTS.md already document what data each module handles, where it flows, who receives it, and what security measures are in place. A ROPA is largely this same information presented in the specific format regulators and DPOs need to inspect. Without this skill, someone has to manually trace data flows across every module and interview every team. With it, the draft is generated in one session and the lawyer review focuses on legal analysis rather than archaeology.
The risk is overconfidence — a ROPA that looks complete but is missing processing activities because some modules lack context files. Flag every gap explicitly so the reviewer knows what to verify.
Arguments
- (none) — scans the entire repo
--module path/to/module — generates a ROPA entry for one module only
Phase 1: Discover PII-processing modules
Scan all MODULE_MANIFEST.md files in the repo (use Glob for **/MODULE_MANIFEST.md). For each, look for:
- Data classification sections mentioning: PII, personal data, user data, personal information, GDPR, health data, financial data, identity, email, name, address, phone
- Retention or residency constraints
Scan all BEHAVIORAL_CONTRACTS.md files for interfaces whose input or output fields include user-identifiable data.
Track which modules were found with and without context files. A source directory that handles data but has no MODULE_MANIFEST.md is a gap — flag it explicitly at the end.
Phase 2: Group into processing activities
ROPA entries map to processing activities, not to modules. Multiple modules often participate in one activity. Group by logical purpose:
- "User authentication" might involve auth module, session module, and audit log module
- "Payment processing" might involve billing module, payment gateway client, and transaction log module
- "Analytics" might involve event ingestion, aggregation, and reporting modules
Present the proposed groupings to the user before proceeding:
I've identified the following processing activities from context files:
1. User account management — modules: auth/, profile/, audit-log/
2. Payment processing — modules: billing/, payment-gateway/, transactions/
3. Analytics and reporting — modules: events/, aggregations/, reporting/
Modules with no context files (these activities may be incomplete):
- recommendations/ — handles user_id but has no MODULE_MANIFEST.md
Do these groupings look right? Should I split or combine any?
Wait for confirmation before continuing.
Phase 3: Auto-populate from context layers
For each confirmed processing activity, extract:
| ROPA field | Where to look |
|---|
| Processing activity name | Derive from module purpose fields |
| Categories of personal data | Data classification fields across all modules in the activity |
| Categories of data subjects | Infer from data types — customers, employees, prospects, minors (flag if unclear) |
| Recipients | Dependents + shared resource consumers from MODULE_MANIFEST.md |
| Retention periods | Retention/residency constraints; mark "Not documented" if absent |
| Security measures | Data classification, access controls, encryption notes in contracts |
If a field cannot be populated, mark it [REQUIRED — see Open Questions] rather than leaving it blank or guessing.
Phase 4: Interview for human-judgment fields
For each processing activity, ask these questions. Batch them — don't ask one at a time for every activity:
Legal basis (required by Article 30):
What is the legal basis for processing in [activity name]? Options: Consent / Contractual necessity / Legal obligation / Vital interests / Public task / Legitimate interests. If legitimate interests, what are those interests and has a balancing test been performed?
Processing purpose (must be specific):
What specifically does [activity name] accomplish for the data subject or the organization? "To provide services" is not specific enough — what would be missing if this processing stopped?
International transfers (Article 30(1)(e)):
Does data in [activity name] flow to processors or recipients outside the EU/EEA (including SaaS providers, cloud regions, or analytics platforms)? If yes: what transfer mechanism is in place — adequacy decision, SCCs, or BCRs?
Controller / processor distinction:
For [activity name], is [organization] the data controller, a processor acting on behalf of another controller, or both?
If the user cannot answer a question, mark it [OPEN QUESTION — requires DPO/legal input] and add it to the Open Questions section.
Phase 5: Write the ROPA document
Write to docs/compliance/gdpr-ropa-YYYY-MM-DD.md (where YYYY-MM-DD is today's date). Create the docs/compliance/ directory if it doesn't exist.
Use this structure exactly:
# Records of Processing Activities (ROPA)
Article 30(1), GDPR
Organization: [ask user if not obvious from codebase]
Last updated: [today's date]
Status: DRAFT — requires legal review before submission
> **This document was generated from code context files and requires legal review before use
> as a compliance document.** It may be incomplete, inaccurate, or missing processing activities
> not documented in MODULE_MANIFEST.md. Engage your DPO or legal counsel before submitting this
> as a GDPR Article 30 record.
---
## Processing Activity: [Name]
| Field | Value |
|-------|-------|
| Controller | |
| DPO contact | |
| Purpose of processing | |
| Legal basis | |
| Categories of data subjects | |
| Categories of personal data | |
| Recipients / categories of recipients | |
| International transfers | None identified / [transfer + mechanism] |
| Transfer mechanism (if applicable) | |
| Retention period | |
| Technical and organisational security measures | |
### Modules involved
| Module | Role in this activity |
|--------|----------------------|
| [module path] | [e.g., stores user records, processes payment tokens] |
### Open questions
[Fields that could not be populated — require DPO or legal review before submission]
---
One section per processing activity.
Phase 6: Flag documentation gaps
After writing the ROPA, append a gaps section:
## Documentation Gaps
The following modules appear to process personal data but have incomplete or missing context files.
These activities may be underrepresented in this ROPA.
| Module | Issue |
|--------|-------|
| recommendations/ | No MODULE_MANIFEST.md — data flows unknown |
| [module] | MODULE_MANIFEST.md present but data classification not populated |
**Action required before submitting this ROPA:** Run /context-layer-generator on each module
listed above and re-run /generate-gdpr-ropa.
After writing
Report:
- How many processing activities were documented
- How many open questions remain
- How many modules have documentation gaps
- Path to the generated file
Remind the user that legal review is required before this document is used as a compliance submission.
