erasure-guardlisted

Audit whether a "delete my account" / erasure feature actually removes a user's data everywhere it's copied, not just the primary table an ORM cascade covers. Maps every destination data reaches — replicas, caches, search indices, materialized views, analytics pipelines, third-party processors, warehouse snapshots, backups — checks whether deletion calls into each one, and classifies each as must-hard-delete, acceptable-to-anonymize (retained financial/audit records), or acceptable-"beyond use" until cycle-out (backups). Distinct from `tombstone` (unused code, not an active deletion feature), `secret-spill` (credentials, not user data), `stale-guard` (general cache correctness), and GDPR/DSAR compliance packs (consent workflow, not this completeness check). Use when adding/reviewing a deletion endpoint, when a new data store might not be wired into it, or when asked "does deleting a user delete everything", "GDPR erasure audit", "right to be forgotten", or "where does user data still live after deletion".
0xmortuex/claude-code-skills · ★ 0 · AI & Automation · score 72

Install: claude install-skill 0xmortuex/claude-code-skills

# erasure-guard Deleting a user is easy in the one place everyone tests: the primary users table, with `ON DELETE CASCADE` tidying up the foreign keys an ORM knows about. It's the places nobody was thinking about when that endpoint shipped where the data survives — the search index that got its own denormalized copy for query speed, the analytics event that already left for a third-party pipeline before the delete ran, the nightly warehouse ETL that snapshotted the row the day before, the cache entry keyed by user ID that nothing ever explicitly evicts. Each of these was correct the day it was built. The deletion pipeline just wasn't updated when they were added — a gap real enough that GitHub's own engineering-focused GDPR skill lists "erasure pipeline updated to cover new data store" as a PR-checklist reminder, which only exists because teams keep needing reminding. This skill is the systematic check that reminder can't be: it doesn't trust that the checklist was followed, it verifies the pipeline against every store that actually exists today. ## Step 1: map every place this user's identifiable data materializes Don't start from the deletion code — start from the data. Grep for every table, index, cache namespace, and outbound integration that stores or forwards anything keyed to a user: FK-linked tables (the easy, usually-correct part), read replicas (usually fine, they follow the primary, but confirm replication isn't excluded for any table), search/index stores that