agentsclimarketplace

Auto deletion workflow

Skill onfire7777/universal-ai-skills-library/skills/auto-deletion-workflow

Implements automated data deletion workflows for GDPR Article 17 right to erasure and retention period expiry. Covers cascading deletion across dependent systems, dependency handling for referential integrity, confirmation logging, and audit trail generation. Activate for automated deletion, erasure automation, data purge, retention expiry queries.From its SKILL.md

Install
npx -y skills add onfire7777/universal-ai-skills-library --skill auto-deletion-workflow

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 13 stars13 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its file declares

Copied from the file, not written here

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

17.4 KB, ~3.7k tokens by cl100k_base, as published. Nobody here has run it

Automated Data Deletion Workflow

Overview

Automated deletion workflows ensure that personal data is removed from all systems when retention periods expire or when a valid erasure request is received under GDPR Article 17. Manual deletion at scale is error-prone and fails to meet the storage limitation principle consistently. This skill defines the architecture, logic, and operational procedures for building automated deletion pipelines that handle cascading dependencies, maintain referential integrity, produce audit-grade confirmation logs, and satisfy both scheduled retention expiry and on-demand erasure requests.

Legal Foundation

GDPR Article 17(1) — Right to Erasure

The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay, and the controller shall have the obligation to erase personal data without undue delay where one of the specified grounds applies.

GDPR Article 5(1)(e) — Storage Limitation

Personal data shall be kept for no longer than is necessary for the purposes for which the personal data are processed. Automated deletion is the primary technical measure for enforcing this principle at scale.

GDPR Article 25(1) — Data Protection by Design

The controller shall implement appropriate technical and organisational measures designed to implement data-protection principles, such as data minimisation, in an effective manner. Automated deletion is a core by-design control.

GDPR Article 30(1)(f) — Envisaged Time Limits for Erasure

Records of processing activities must include, where possible, the envisaged time limits for erasure of the different categories of data. Automated deletion systems operationalize these envisaged time limits.

Automated Deletion Architecture

Deletion Trigger Types

Trigger TypeSourceSLAPriority
Retention expiryRetention schedule metadata reaching calculated deletion dateWithin 30 days of expiryStandard
Data subject erasure requestVerified Art. 17 request via DSAR workflowWithin 30 calendar days of verified requestHigh
Consent withdrawalConsent management platform eventWithin 30 days (best practice: 72 hours)High
Account closureCustomer account termination eventPer retention schedule (post-closure retention period)Standard
Purpose completionProcessing purpose fulfilled, no further legal basisWithin 30 days of purpose completionStandard
Legal hold releaseLitigation hold lifted by Legal counselWithin 14 days of hold releaseStandard

System Architecture

┌─────────────────────────────────────────────────────────────┐
│                   DELETION ORCHESTRATOR                      │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────────┐  │
│  │  Trigger      │  │  Dependency  │  │  Execution       │  │
│  │  Engine       │  │  Resolver    │  │  Engine          │  │
│  │              │  │              │  │                  │  │
│  │ - Scheduled   │  │ - FK mapping │  │ - System agents  │  │
│  │ - Event-driven│  │ - Cascade    │  │ - API calls      │  │
│  │ - On-demand   │  │   rules      │  │ - Direct DB ops  │  │
│  │ - Hold check  │  │ - Orphan     │  │ - File system    │  │
│  │              │  │   handling   │  │   purge          │  │
│  └──────┬───────┘  └──────┬───────┘  └────────┬─────────┘  │
│         │                 │                    │             │
│         └────────┬────────┘                    │             │
│                  ▼                             │             │
│  ┌──────────────────────────┐                 │             │
│  │  Deletion Job Queue      │─────────────────┘             │
│  │  (Priority-ordered)      │                               │
│  └──────────────────────────┘                               │
│                  │                                           │
│                  ▼                                           │
│  ┌──────────────────────────┐  ┌──────────────────────────┐ │
│  │  Confirmation Logger     │  │  Audit Trail Generator   │ │
│  │  - Per-system status     │  │  - Immutable audit log   │ │
│  │  - Completion timestamp  │  │  - Deletion certificate  │ │
│  │  - Verification hash     │  │  - Regulatory report     │ │
│  └──────────────────────────┘  └──────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘

Deletion Workflow Procedures

Workflow 1: Scheduled Retention Expiry Deletion

[Daily Retention Scan — 02:00 UTC]
         │
         ▼
[Query all records where calculated_deletion_date <= TODAY + 30 days]
         │
         ▼
[For each record approaching expiry]
   │
   ├── [Check: Active litigation hold?]
   │     ├── Yes ──► [Skip — log hold reference, notify Legal]
   │     └── No ──► Continue
   │
   ├── [Check: Active regulatory investigation?]
   │     ├── Yes ──► [Skip — log investigation reference]
   │     └── No ──► Continue
   │
   ├── [Check: Pending data subject request referencing this data?]
   │     ├── Yes ──► [Coordinate with DSAR workflow]
   │     └── No ──► Continue
   │
   ├── [Check: Retention exception approved?]
   │     ├── Yes ──► [Skip — log exception reference and expiry]
   │     └── No ──► Continue
   │
   ▼
[Add to deletion job queue with priority: STANDARD]
         │
         ▼
[On calculated_deletion_date: Execute deletion]

Workflow 2: On-Demand Erasure Request Deletion

[Verified Art. 17 Erasure Request Received]
         │
         ▼
[Data Discovery — Identify all instances of data subject's data]
   │
   ├── Primary databases (CRM, ERP, HR system)
   ├── Data warehouse and analytics platforms
   ├── File storage (SharePoint, network drives, cloud storage)
   ├── Email and communication systems
   ├── Backup and archive systems
   ├── Third-party processor systems
   └── Logs and audit trails
         │
         ▼
[Generate Deletion Manifest]
   Reference: DEL-YYYY-NNNN
   Data Subject: [Pseudonymised reference]
   Systems identified: [List with record counts]
   Exceptions identified: [Any Art. 17(3) exceptions]
   Estimated completion: [Date]
         │
         ▼
[DPO Review and Approval]
   ├── Approved ──► [Add to deletion job queue with priority: HIGH]
   └── Exceptions found ──► [Partial deletion — exclude excepted data]
         │
         ▼
[Execute deletion across all identified systems]

Workflow 3: Cascading Deletion Logic

When deleting a primary record, dependent records across related systems must also be deleted. The cascading deletion resolver handles referential integrity:

[Primary Record Identified for Deletion]
         │
         ▼
[Load Dependency Map for Record Type]
         │
         ▼
[Resolve Dependencies — Depth-First Traversal]
   │
   ├── [Level 0: Primary record]
   │     Example: Customer record in CRM
   │
   ├── [Level 1: Direct dependents]
   │     Example: Orders, support tickets, consent records
   │
   ├── [Level 2: Secondary dependents]
   │     Example: Order line items, payment records, shipping records
   │
   └── [Level 3+: Tertiary dependents]
         Example: Invoice line items, refund records
         │
         ▼
[For each dependent record]
   │
   ├── [Shared dependency?]
   │     (Record also linked to other primary records not being deleted)
   │     ├── Yes ──► [Nullify foreign key — do NOT delete]
   │     └── No ──► [Add to deletion manifest]
   │
   ├── [Legal retention override?]
   │     (Dependent record has its own statutory retention requirement)
   │     ├── Yes ──► [Anonymize link to primary record, retain dependent]
   │     └── No ──► [Add to deletion manifest]
   │
   └── [Aggregated/statistical record?]
         (Record contributes to aggregated reporting)
         ├── Yes ──► [Anonymize — remove personal identifiers, retain aggregate]
         └── No ──► [Add to deletion manifest]
         │
         ▼
[Execute deletion in reverse order (deepest dependents first)]
   Level 3+ ──► Level 2 ──► Level 1 ──► Level 0

Dependency Map Template

The following dependency map is configured for Orion Data Vault Corp:

Primary EntityDependent EntityRelationshipDeletion ActionRetention Override
CustomerOrders1:NCascade delete (after statutory retention)6 years — HMRC
CustomerSupport Tickets1:NCascade delete3 years — limitation period
CustomerConsent Records1:NCascade deleteRetain suppression record
CustomerMarketing Preferences1:1Cascade deleteRetain opt-out on suppression list
CustomerAccount Audit Log1:NAnonymize (nullify customer reference)7 years — audit retention
OrderOrder Lines1:NCascade deleteFollows order retention
OrderPayment Records1:NAnonymize6 years — financial records
OrderShipping Records1:NCascade deleteFollows order retention
OrderInvoices1:NAnonymize6 years — tax records
EmployeePayroll Records1:NCascade delete (after statutory retention)6 years — PAYE Regulations
EmployeePerformance Reviews1:NCascade deleteDuration of employment + 6 years
EmployeeAccess Logs1:NAnonymize2 years — security retention

Confirmation Logging

Deletion Confirmation Record Structure

Every deletion execution produces an immutable confirmation record:

DELETION CONFIRMATION RECORD — Orion Data Vault Corp
-----------------------------------------------------
Reference: DEL-2026-0142
Trigger: Retention expiry / Art. 17 request / Consent withdrawal
Data Subject Reference: DS-HASH-a3f8c2e1
Request Date: 2026-02-15 (if applicable)
Execution Date: 2026-03-14
Completed Date: 2026-03-14T14:23:07Z

SYSTEMS PROCESSED:
┌─────────────────────────┬──────────┬───────────────┬──────────────────┐
│ System                  │ Records  │ Action        │ Status           │
├─────────────────────────┼──────────┼───────────────┼──────────────────┤
│ CRM (Salesforce)        │ 1        │ Hard delete   │ Confirmed        │
│ ERP (SAP)               │ 47       │ Hard delete   │ Confirmed        │
│ Data Warehouse (BQ)     │ 312      │ Hard delete   │ Confirmed        │
│ Email (Exchange)        │ 23       │ Hard delete   │ Confirmed        │
│ File Storage (S3)       │ 8        │ Hard delete   │ Confirmed        │
│ Backup (Veeam)          │ N/A      │ Flagged       │ Pending (cycle)  │
│ Analytics (Mixpanel)    │ 156      │ Hard delete   │ Confirmed        │
│ Support (Zendesk)       │ 12       │ Hard delete   │ Confirmed        │
│ Audit Log               │ 89       │ Anonymized    │ Confirmed        │
│ Payment (Stripe)        │ 5        │ Anonymized    │ Confirmed        │
└─────────────────────────┴──────────┴───────────────┴──────────────────┘

THIRD-PARTY NOTIFICATIONS (Art. 19):
- Processor A (Analytics SaaS): Notified 2026-03-14, confirmed 2026-03-16
- Processor B (Email service): Notified 2026-03-14, confirmed 2026-03-15
- Processor C (Payment gateway): Notified 2026-03-14, pending

EXCEPTIONS APPLIED:
- Financial records (invoices): Anonymized, retained until 2032-03-14 (6-year statutory period)
- Audit log entries: Anonymized, retained until 2033-03-14 (7-year audit retention)

BACKUP DELETION:
- Backup system: Next full rotation cycle completes 2026-06-12
- Expected complete erasure from backups: 2026-06-12

VERIFICATION:
- Post-deletion scan completed: 2026-03-14T14:45:00Z
- Residual data found: None
- Verification hash: SHA-256:e3b0c44298fc1c149afbf4c8996fb924...

Executed by: Deletion Orchestrator v3.2 (automated)
Reviewed by: [DPO Name] (for Art. 17 requests only)

Audit Trail Requirements

  1. Immutability: Deletion confirmation records are written to an append-only audit log (write-once storage or blockchain-anchored hash).
  2. Retention of confirmation records: 3 years from deletion date (sufficient to demonstrate compliance if challenged).
  3. No personal data in logs: Confirmation records reference data subjects by pseudonymised identifier only — never by name, email, or other direct identifier.
  4. Searchability: Records must be searchable by deletion reference, data subject hash, trigger type, system, and date range.

Error Handling and Retry Logic

Deletion Failure Handling

Failure TypeActionRetryEscalation
System unavailableQueue for retry3 attempts at 1h, 4h, 24h intervalsAlert IT Operations after 3 failures
Permission deniedLog error, flag for manual reviewNo automatic retryEscalate to system administrator
Referential integrity violationRoute to dependency resolverRe-resolve dependencies, retryEscalate to DPO if unresolvable
Partial deletion (some records failed)Log successful deletions, retry failed3 attemptsEscalate to IT + DPO
Third-party processor non-responseSend reminder at 7 daysFollow up at 14 daysEscalate to DPO + Legal at 21 days
Backup system — cannot delete from active backupFlag for next rotation cycleMonitor backup rotation scheduleAlert if not completed within 90 days

Rollback Considerations

Deletion is inherently irreversible. Therefore:

  1. Pre-deletion snapshot: For Art. 17 requests, take a temporary encrypted snapshot of the data to be deleted. Retain for 72 hours after deletion execution to allow for error correction. Auto-destroy after 72 hours.
  2. Staged execution: For large-scale retention expiry deletions (>10,000 records), execute in batches of 1,000 with verification between batches.
  3. Dry-run mode: All new deletion rules must be tested in dry-run mode for 30 days before activation. Dry-run produces the deletion manifest and confirmation record without executing actual deletion.

Monitoring and Reporting

Key Metrics

MetricTargetMeasurement
Retention expiry deletion completion rate99.5% within 30 days of expiryMonthly
Art. 17 erasure request completion rate100% within 30 calendar daysPer request
Average deletion execution time< 4 hours (end-to-end across all systems)Per execution
Failed deletion rate< 0.5%Monthly
Backup deletion completion rate100% within backup rotation cyclePer rotation
Third-party processor confirmation rate100% within 14 daysPer notification

Quarterly Compliance Report

The automated deletion system generates a quarterly report containing:

  1. Total records deleted by trigger type (retention expiry, Art. 17, consent withdrawal, etc.)
  2. Deletion completion rates against SLA targets
  3. Exceptions applied (with legal basis breakdown)
  4. Failed deletions and resolution status
  5. Third-party processor compliance rates
  6. Backup deletion status and outstanding items
  7. Trend analysis (volume growth, system coverage, performance)

What ships with it: 4 files

17.3 KB alongside SKILL.md, 1 of them executable

assets/

references/

scripts/

Keep looking

Skills are one crate of 326,835. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.