Comply

Comply — Compliance & Governance

Activate When

• User invokes /godmode:comply
• User says "are we GDPR compliant?", "audit trail", "privacy review", "compliance check"
• Team builds features handling personal data, health data, or payment data
• Pre-ship check when /godmode:ship detects regulated data flows
• User needs license compliance audit across dependencies
• Preparing for SOC2 audit or regulatory review

Workflow

Step 1: Define Compliance Scope

Determine which regulations and what code is in scope:

COMPLIANCE SCOPE:
Target: 
Applicable regulations:
  - [ ] GDPR (personal data of EU residents)
  - [ ] HIPAA (protected health information)
  - [ ] SOC2 (service organization controls)
  - [ ] PCI-DSS (payment card data)
  - [ ] CCPA (California consumer privacy)
  - [ ] FERPA (educational records)
  - [ ] Other: 

Data classification:
  Personal data: 
  Sensitive data: 
  Public data: 

Step 2: GDPR Compliance Check

If personal data of EU residents is processed:

Lawful Basis

GDPR — LAWFUL BASIS ASSESSMENT:
| Data Processing Activity | Lawful Basis | Status |
|--|--|--|
| User registration | Consent | COMPLIANT |
| Order processing | Contract | COMPLIANT |
| Marketing emails | Consent | MISSING |
| Analytics tracking | Legitimate int. | REVIEW |
| Fraud detection | Legitimate int. | COMPLIANT |

Data Subject Rights

GDPR — DATA SUBJECT RIGHTS:
| Right | Implemented | Location |
|--|--|--|
| Right to access | YES/NO |  |
| Right to rectification | YES/NO |  |
| Right to erasure | YES/NO |  |
| Right to portability | YES/NO |  |
| Right to restrict proc. | YES/NO |  |
| Right to object | YES/NO |  |
| Automated decision-making | YES/NO/N/A |  |

Consent Management

CONSENT IMPLEMENTATION CHECK:
- [ ] Consent is freely given (not bundled with service access)
- [ ] Consent is specific (separate consent per purpose)
- [ ] Consent is informed (clear language, not legalese)
- [ ] Consent is unambiguous (affirmative action, no pre-ticked boxes)
- [ ] Consent is withdrawable (easy opt-out, same effort as opt-in)
- [ ] Consent records stored (who, when, what, version of terms)
- [ ] Under-16 users: parental consent mechanism exists

Step 3: HIPAA Compliance Check

If protected health information (PHI) is processed:

HIPAA — SAFEGUARDS ASSESSMENT:
| Safeguard | Status | Evidence |
  ADMINISTRATIVE SAFEGUARDS
| Risk analysis conducted | YES/NO |  |
|--|--|--|
| Workforce access controls | YES/NO |  |
| Security awareness training | YES/NO |  |
| Incident response procedures | YES/NO |  |
| Business associate agreements | YES/NO |  |
  PHYSICAL SAFEGUARDS
| Facility access controls | YES/NO |  |
|--|--|--|
| Workstation security | YES/NO |  |
| Device and media controls | YES/NO |  |

Step 4: SOC2 Compliance Check

If operating as a service organization:

SOC2 — TRUST SERVICES CRITERIA:
| Category | Controls | Implemented | Gaps |
|--|--|--|--|
| Security | 12 |  |  |
| Availability | 8 |  |  |
| Processing Integr. | 6 |  |  |
| Confidentiality | 7 |  |  |
| Privacy | 10 |  |  |

Key SOC2 Controls:
- [ ] Change management process documented and followed
- [ ] Logical access controls with least privilege
- [ ] Encryption in transit and at rest
- [ ] Monitoring and alerting for security events
- [ ] Incident response plan tested within last 12 months

Step 5: PCI-DSS Compliance Check

If payment card data is processed:

PCI-DSS — REQUIREMENTS CHECK:
| Requirement | Status |
|--|--|
| 1. Network security controls | PASS/FAIL |
| 2. Secure configuration | PASS/FAIL |
| 3. Protect stored account data | PASS/FAIL |
| 4. Encrypt transmission over networks | PASS/FAIL |
| 5. Protect from malicious software | PASS/FAIL |
| 6. Secure systems and software | PASS/FAIL |
| 7. Restrict access by business need | PASS/FAIL |
| 8. Identify users and auth access | PASS/FAIL |
| 9. Restrict physical access | PASS/FAIL/N/A |
| 10. Log and monitor all access | PASS/FAIL |
| 11. Test security regularly | PASS/FAIL |

Step 6: Audit Trail Design & Validation

Verify that all security and compliance events are logged:

AUDIT TRAIL ASSESSMENT:
| Event Category | Logged | Fields |
|--|--|--|
| Authentication | YES/NO | who, when, IP, result |
| Authorization changes | YES/NO | who, what, when, by-whom |
| Data access (read) | YES/NO | who, what, when |
| Data modification | YES/NO | who, what, old, new |
| Data deletion | YES/NO | who, what, when, reason |
| Data export | YES/NO | who, what, format, dest |
| Configuration changes | YES/NO | who, what, old, new |
| System errors | YES/NO | what, when, severity |
| Admin operations | YES/NO | who, what, when |

Step 7: Data Retention & Deletion

Verify data lifecycle management:

DATA RETENTION POLICY:
| Data Category | Retention | Auto-delete | Method |
|--|--|--|--|
| User accounts | Active+2y | YES/NO |  |
| Transaction logs | 7 years | YES/NO |  |
| Session data | 30 days | YES/NO |  |
| Audit logs | 3 years | YES/NO |  |
| Analytics data | 1 year | YES/NO |  |
| Backup data | 90 days | YES/NO |  |
| Temporary files | 24 hours | YES/NO |  |

Deletion workflow:
- [ ] Deletion request → verification → execution → confirmation
- [ ] Deletion cascades to all copies (backups, caches, replicas)
- [ ] Deletion is verifiable (can prove data no longer exists)

Step 8: License Compliance

Audit dependencies: MIT/Apache/BSD/ISC = safe. LGPL = review. GPL/AGPL = replace or verify no copyleft trigger. Unlicensed = investigate/replace. Verify NOTICE/LICENSE files included in distribution.

Step 9: Compliance Report

  COMPLIANCE AUDIT REPORT
  Regulations assessed:
  GDPR:     
  HIPAA:    
  SOC2:     
  PCI-DSS:  
  Findings:
  CRITICAL:  (must fix before launch)
  HIGH:      (must fix within 30 days)
  MEDIUM:    (should fix within 90 days)
  LOW:       (best practice, not required)

Step 10: Commit and Transition

1. Save report as docs/compliance/-compliance-audit.md
2. Commit: "comply: — ( findings across )"
3. If NON-COMPLIANT: "Critical compliance gaps found. Fix these before launch. Run /godmode:fix to remediate."
4. If COMPLIANT: "Compliance audit passed. Ready for /godmode:ship."

Key Behaviors

# Run compliance checks
npx license-checker --production --failOn "GPL-3.0;AGPL-3.0"
grep -rn "email\|ssn\|password" src/ --include="*.ts" | head -20
git log --oneline --since="30 days" -- docs/compliance/

IF CRITICAL findings > 0: block launch until resolved. WHEN HIGH findings > 0: remediation plan with 99% passing rate

• High-severity findings: 90 days minimum

HARD RULES

1. NEVER STOP until all applicable regulations are assessed and all findings are documented.
2. NEVER provide legal advice — identify technical gaps, recommend consulting legal counsel for interpretation.
3. EVERY finding MUST reference a specific regulation article (e.g., "GDPR Article 17" not "deletion missing").
4. EVERY finding MUST point to actual code — file paths, line numbers, functions. No theoretical assessments.
5. git commit BEFORE verify — commit the compliance report, then verify all findings are actionable.
6. Automatic revert on regression — if a remediation introduces new compliance gaps, revert immediately.
7. TSV logging — log every compliance scan:

`` timestamp regulation scope critical high medium low verdict ``

1. NEVER log PII in audit trails — log user IDs, not names/SSNs/emails.

Explicit Loop Protocol

FOR each applicable regulation:
  1. Scan codebase for data flows
  2. Check controls against requirements
  3. For each NON_COMPLIANT finding: record with evidence
  4. STOP when all regulations assessed

Auto-Detection

On activation, automatically detect compliance scope:

AUTO-DETECT:
1. Data types handled:
   grep -r "email\|password\|ssn\|credit.card\|phone\|address\|dob\|birth" src/ --include="*.ts" --include="*.py" -l
     2>/dev/null
   # Determines: PII present -> GDPR/CCPA scope

2. Health data:
   grep -ri "patient\|diagnosis\|medical\|health\|phi\|hipaa" src/ -l 2>/dev/null
   # Determines: PHI present -> HIPAA scope

3. Payment data:
   grep -ri "stripe\|payment\|credit.card\|pan\|cvv\|billing" src/ -l 2>/dev/null
   # Determines: Payment data -> PCI-DSS scope

4. Existing compliance artifacts:

Output Format

Every comply invocation must produce a structured report:

  COMPLIANCE RESULT
  Regulations assessed: 
  GDPR: 
  HIPAA: 
  SOC2: 
  PCI-DSS: 
  Findings: C H M L
  Audit trail: 
  License risk: 
  Verdict: 

Keep/Discard

KEEP if: improvement verified. DISCARD if: regression or no change. Revert discards immediately.

Stop Conditions

Stop when: target reached, budget exhausted, or >5 consecutive discards.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: arbazkhan971
• Source: arbazkhan971/godmode
• License: MIT

Install and usage instructions live in the source repository linked above.