Help us improve
Share bugs, ideas, or general feedback.
From legal
Run a compliance check on a proposed action, product feature, or business initiative, surfacing applicable regulations, required approvals, and risk areas. Use when launching a feature that touches personal data, when marketing or product proposes something with regulatory implications, or when you need to know which approvals and jurisdictional requirements apply before proceeding.
npx claudepluginhub sun2443/designer-skills --plugin legalHow this skill is triggered — by the user, by Claude, or both
Slash command
/legal:compliance-check <action or initiative to check><action or initiative to check>The summary Claude sees in its skill listing — used to decide when to auto-load this skill
> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.
Share bugs, ideas, or general feedback.
If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.
Run a compliance check on a proposed action, product feature, marketing campaign, or business initiative.
Important: This command assists with legal workflows but does not provide legal advice. Compliance assessments should be reviewed by qualified legal professionals. Regulatory requirements change frequently; always verify current requirements with authoritative sources.
/compliance-check $ARGUMENTS
Describe what you're planning to do. Examples:
## Compliance Check: [Initiative]
### Summary
[Quick assessment: Proceed / Proceed with conditions / Requires further review]
### Applicable Regulations and Policies
| Regulation/Policy | Relevance | Key Requirements |
|-------------------|-----------|-----------------|
| [GDPR / CCPA / HIPAA / etc.] | [How it applies] | [What you need to do] |
### Requirements
| # | Requirement | Status | Action Needed |
|---|-------------|--------|---------------|
| 1 | [Requirement] | [Met / Not Met / Unknown] | [What to do] |
### Risk Areas
| Risk | Severity | Mitigation |
|------|----------|------------|
| [Risk] | [High/Med/Low] | [How to address] |
### Recommended Actions
1. [Most important action]
2. [Second priority]
3. [Third priority]
### Approvals Needed
| Approver | Why | Status |
|----------|-----|--------|
| [Person/Team] | [Reason] | [Pending] |
### Further Review Recommended
[Areas where outside counsel or specialist review is advised]
Scope: Applies to processing of personal data of individuals in the EU/EEA, regardless of where the processing organization is located.
Key Obligations for In-House Legal Teams:
Common In-House Legal Touchpoints:
Scope: Applies to businesses that collect personal information of California residents and meet revenue, data volume, or data sale thresholds.
Key Obligations:
Response Timelines:
| Regulation | Jurisdiction | Key Differentiators |
|---|---|---|
| LGPD (Brazil) | Brazil | Similar to GDPR; requires DPO appointment; National Data Protection Authority (ANPD) enforcement |
| POPIA (South Africa) | South Africa | Information Regulator oversight; required registration of processing |
| PIPEDA (Canada) | Canada (federal) | Consent-based framework; OPC oversight; being modernized |
| PDPA (Singapore) | Singapore | Do Not Call registry; mandatory breach notification; PDPC enforcement |
| Privacy Act (Australia) | Australia | Australian Privacy Principles (APPs); notifiable data breaches scheme |
| PIPL (China) | China | Strict cross-border transfer rules; data localization requirements; CAC oversight |
| UK GDPR | United Kingdom | Post-Brexit UK version; ICO oversight; similar to EU GDPR with UK-specific adequacy |
When reviewing a Data Processing Agreement or Data Processing Addendum, verify the following:
| Issue | Risk | Standard Position |
|---|---|---|
| Blanket sub-processor authorization without notification | Loss of control over processing chain | Require notification with right to object |
| Breach notification timeline > 72 hours | May prevent timely regulatory notification | Require notification within 24-48 hours |
| No audit rights (or audit rights only via third-party reports) | Cannot verify compliance | Accept SOC 2 Type II + right to audit upon cause |
| Data deletion timeline not specified | Data retained indefinitely | Require deletion within 30-90 days of termination |
| No data processing locations specified | Data could be processed anywhere | Require disclosure of processing locations |
| Outdated SCCs | Invalid transfer mechanism | Require current EU SCCs (2021 version) |
When a data subject request is received:
Identify the request type:
Identify applicable regulation(s):
Verify identity:
Log the request:
| Regulation | Initial Acknowledgment | Substantive Response | Extension |
|---|---|---|---|
| GDPR | Not specified (best practice: promptly) | 30 days | +60 days (with notice) |
| CCPA/CPRA | 10 business days | 45 calendar days | +45 days (with notice) |
| UK GDPR | Not specified (best practice: promptly) | 30 days | +60 days (with notice) |
| LGPD | Not specified | 15 days | Limited extensions |
Before fulfilling a request, check whether any exemptions apply:
Common exemptions across regulations:
Organization-specific considerations:
Maintain awareness of developments in:
Escalate regulatory developments to senior counsel or leadership when: