data-lineage-trace

name	data-lineage-trace
description	Use when you need to prove where a piece of data (PII, PHI, payment data, customer identifier) originates, where it flows through the system, where it lands, and who reads it. Triggers on: data lineage, PII flow, GDPR right-to-erasure, data residency, schema change, retention policy, 'where does field X come from', 'who reads PII column Y', 'walk this field end to end', deletion propagation, audit trail, data classification. Do NOT use for: static code review (use java-code-reviewer, react-code-reviewer, go-code-reviewer, python-code-reviewer, or node-code-reviewer for that), or for design-time brainstorming (use obra/superpowers brainstorming). Complementary to goal-driven-development, which orchestrates the spec-to-code flow; data-lineage-trace is the regulated-data counterpart that runs after a change lands.
metadata	{"short-description":"PII / PHI / regulated-field lineage end to end"}

Data Lineage Trace

Trace a regulated data field from producer to sink. Forward walk for ingestion, backward walk for deletion, full graph for classification. The output is an audit-trail artefact, not a review finding.

Required Loading

Always load:

• prompts/lineage-walk.md — the producer/transformer/consumer/retention framework; the four lineage report sections.

When To Run

• After a schema change that adds or renames a regulated field.
• After a new persistence sink is added (warehouse, analytics, export job).
• When a GDPR / HIPAA / PCI / SOC 2 right-to-erasure request arrives.
• When a regulator asks "show me every site that touches <field>".
• When a feature team is about to consume a field and wants to know what it actually is (column vs computed vs joined).