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.
How 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).
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.
Lark-native execution (depth core: LARK-PATTERNS, LARK-RECIPES, LARK-FUSION).
- Pull internal precedent (prior DPIAs, privacy notices, DPA reviews) from Wiki/Docs (
lark_doc_search,lark_doc_fetchwithjqprojection, P3) before assessing.- Keep a compliance register / DPA-review log in a Lark Base (P5): read existing entries with
lark_base_search(REQUIRESsearch_fields; nojq— narrow withselect_fields/limit, read.data.records[]; discover field names vialark_apiGET /open-apis/bitable/v1/apps/{base}/tables/{table}/fieldsif unknown), write the check result withlark_base_record_upsert. Don't hand-roll the schema — scaffold viabase-deploy; CRUD/formula depth →lark-base.- Surface the assessment as an interactive card (P4) via
lark_im_card_send— coloredheader(green Proceed / orange Conditions / red Review),panelper section (regulations, risks, approvals),itemrows for each required action.print_json: true→dry_run: true→ send.- For each Approval Needed, resolve the approver (
lark_contact_search, P1) and create a real Lark approval instance (P7,lark_apiapproval recipe /lark-approvalskill) — not an ad-hoc "reply yes". DPIA sign-offs, cross-border-transfer approvals and data-subject-request closures should be tracked there.- Capture follow-up actions as Lark Tasks (
lark_task_create, resolve owner first,dry_run, P2). Land a durable compliance memo in Wiki (lark_wiki_node_create, P8).
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 — write it to the DSR-tracking Lark Base (P5) via lark_base_record_upsert (dry_run first, P2) with these fields:
open_id via lark_contact_search, P1)Then create a Lark Task for the handler (lark_task_create with due = the response deadline) and, if useful, a calendar reminder (lark_calendar_create) so the regulatory clock (e.g. GDPR 30-day / CCPA 45-day) is tracked natively.
| 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:
npx claudepluginhub larkcowork/lark-cowork-plugins --plugin legalGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.