出海助手-GDPR合规 / GDPR Compliance

> 本技能改造自开源技能 gdpr-compliance（来源：TerminalSkills/skills，TerminalSkills 开源技能库）。已完整保留原始运行文件（scripts/references/assets 与 LICENSE），并新增中文出海使用说明。原始英文说明见文末「English (Original)」与同目录 SKILL.original.md。

功能说明 / Functional Overview

面向欧盟市场的 GDPR 合规检查与落地指引：数据主体权利、数据处理协议、Cookie 同意与违规风险。

适用场景 / Use Cases

• 出海产品欧盟合规自查
• 隐私政策/Cookie 同意方案
• 数据处理协议（DPA）要点

使用方法 / How to Use

1. 描述业务场景（收集了哪些数据、面向哪些国家），技能给出合规清单与整改建议。
2. 涉及具体法条与判例，正文保留英文术语（如 DPA、DPIA）。

示例 / Examples

• 「出海产品欧盟合规自查」——用自然语言把任务交给本技能即可。

限制说明 / Limitations

• 需要外部服务/凭证的技能，请先完成授权配置后使用。
• 本技能为开源技能的中文本地化版本，核心逻辑与原技能一致；如遇专业术语，正文保留英文原词（如 Shopify、SEO、GA4 等）。

English (Original) / 英文原文（完整保留）

> The section below is the original skill definition, preserved verbatim for traceability and full functionality.

GDPR Compliance

Overview

This skill helps AI agents implement GDPR compliance across web applications. It covers the full lifecycle: auditing where personal data lives, building consent management, handling data subject requests (access, deletion, portability), enforcing retention policies, and generating documentation.

Instructions

PII Audit

1. Scan database schemas (Prisma, SQL migrations, Sequelize models, TypeORM entities) for PII fields. Flag these patterns:
   - Direct identifiers: email, name, full_name, phone, address, ssn
   - Indirect identifiers: ip_address, device_id, geo_*, lat, lng, user_agent
   - Sensitive data: date_of_birth, gender, health_*, ethnicity
2. Scan application code for PII in logs: search for console.log, logger.*, winston.* calls that include user objects or request IPs.
3. Scan third-party integrations: check for API calls that send user data (analytics, email providers, payment processors, CRMs).
4. Output a Data Flow Inventory as a markdown table:
   | Data Type | Storage Location | Shared With | Legal Basis | Retention Period |

Consent Management

1. Define consent categories:
   - strictly_necessary — always active, no consent needed
   - functional — preferences, language, UI settings
   - analytics — usage tracking, performance monitoring
   - marketing — ad targeting, remarketing pixels
2. Build a consent banner component that:
   - Blocks all non-necessary scripts until consent is granted
   - Provides granular opt-in/opt-out per category
   - Stores consent in a database table (not just cookies)
3. Consent record schema:
   consent_records: id, user_id, version, strictly_necessary (always true), functional (bool), analytics (bool), marketing (bool), ip_address_hash, created_at
4. On consent change, fire a consent_updated event that other services can listen to for enabling/disabling tracking.

Data Subject Requests (DSR)

Implement three endpoints:

Data Export (Right of Access / Portability):
- Collect all data for the user across all tables where their ID appears.
- Include related records (orders, comments, sessions).
- Return as JSON with a clear structure. Optionally offer CSV.
- Redact any third-party secrets or internal IDs that are not user data.

Data Deletion (Right to Erasure):
- Do NOT immediately delete. Use a 30-day cooling-off queue.
- Send confirmation email with a cancel link.
- After 30 days, either anonymize (replace PII with hashed/null values) or hard-delete.
- Cascade to: logs (redact), sessions (delete), third-party (trigger deletion APIs where available).
- Keep anonymized records for aggregate analytics if needed.

Consent History:
- Return all consent records for the user, ordered by date.
- Include version numbers to show what the user agreed to and when.

Retention Policies

1. Define retention periods per data type based on purpose:
   - Session data: 90 days
   - IP addresses: 30 days (anonymize by zeroing last octet)
   - Soft-deleted accounts: 30 days then hard delete
   - Audit logs: 1 year (legal requirement)
   - Marketing data: until consent withdrawn
2. Build a scheduled job that runs daily and enforces these policies.
3. Always implement dry-run mode first: log what would be affected without deleting.

Privacy Policy Generation

1. Use the Data Flow Inventory to auto-generate a privacy policy that lists:
   - What data is collected
   - Why (legal basis for each type)
   - How long it is kept
   - Who it is shared with
   - User rights and how to exercise them
2. Use plain language — avoid legal jargon where possible.
3. Include placeholder sections for: company name, DPO contact, supervisory authority.

Examples

Example 1 — PII detection in Prisma schema

Input: "Audit this Prisma schema for PII."

model User {
  id        String   @id @default(uuid())
  email     String   @unique
  name      String
  phone     String?
  createdAt DateTime @default(now())
  orders    Order[]
}

Output:

PII fields found in model User:
- email (direct identifier) — requires legal basis, retention policy
- name (direct identifier) — requires legal basis
- phone (direct identifier) — requires legal basis, consider encryption at rest

Recommendations:
1. Add a `deletedAt` field for soft-delete support
2. Add a `consentVersion` field to track which privacy policy version the user agreed to
3. Consider encrypting `phone` at rest using application-level encryption

Example 2 — Data deletion cascade

Input: "Build a deletion handler for a user account."

Output:

async function handleDeletionRequest(userId) {
  // 1. Create deletion request record
  await db.deletionRequest.create({
    data: { userId, status: 'pending', expiresAt: addDays(new Date(), 30) }
  });

  // 2. Send confirmation email with cancel link
  await emailService.send(userId, 'deletion-confirmation', {
    cancelUrl: `${BASE_URL}/api/privacy/cancel-deletion?token=${token}`
  });

  // 3. After 30 days (triggered by cron job):
  // await db.user.update({ where: { id: userId }, data: {
  //   email: `deleted-${hash}@anonymized.local`,
  //   name: 'Deleted User', phone: null
  // }});
  // await db.session.deleteMany({ where: { userId } });
  // await analyticsService.deleteUser(userId);
}

Guidelines

• GDPR compliance is not just technical. Always recommend the client consult a legal professional for their specific jurisdiction.
• Default to opt-out. In the EU, analytics and marketing require explicit opt-in. Never pre-check consent boxes.
• Anonymize over delete when possible. Anonymized data is no longer personal data and can be kept for analytics.
• Log every DSR. Regulators may ask for proof that requests were handled within the 30-day deadline.
• Test deletion cascades thoroughly. Missing a single table or third-party integration means non-compliance.