@jetrabbits/agentic 0.0.1

package/areas/software/data-engineering/prompts/schema-migration.md

@@ -0,0 +1,111 @@
+---
+workflow: schema-migration
+---
+
+# Prompt: `/schema-migration`
+
+Use when: applying a breaking or non-breaking schema change to a data warehouse or dbt source — using expand/contract to avoid downstream breakage.
+
+---
+
+## Example 1 — Breaking column rename (expand/contract)
+
+**EN:**
+```
+/schema-migration
+
+Change: rename column revenue → gross_revenue_usd in raw.orders (BigQuery)
+Breaking: YES — 12 downstream dbt models reference "revenue" directly
+Strategy: expand/contract
+  Phase 1 (Expand): add new column gross_revenue_usd (copy of revenue); keep revenue; deploy dbt models to use gross_revenue_usd
+  Phase 2 (Validate): run 7-day parallel validation — SUM(revenue) = SUM(gross_revenue_usd) per day
+  Phase 3 (Contract): drop column revenue after all downstream models migrated and validated
+Timeline: Phase 1 this sprint; Phase 3 next sprint (safe window)
+Downstream models: models/staging/stg_orders.sql, models/mart/orders_daily.sql (+ 10 others — list attached)
+Stakeholder notification: analytics team must update any direct SQL queries against raw.orders
+```
+
+**RU:**
+```
+/schema-migration
+
+Изменение: переименование столбца revenue → gross_revenue_usd в raw.orders (BigQuery)
+Breaking: ДА — 12 downstream dbt моделей ссылаются на "revenue" напрямую
+Стратегия: expand/contract
+  Фаза 1 (Expand): добавить новый столбец gross_revenue_usd (копия revenue); оставить revenue; задеплоить dbt модели на использование gross_revenue_usd
+  Фаза 2 (Validate): запустить 7-дневную параллельную валидацию — SUM(revenue) = SUM(gross_revenue_usd) за день
+  Фаза 3 (Contract): удалить столбец revenue после миграции и валидации всех downstream моделей
+Timeline: Фаза 1 в этом спринте; Фаза 3 в следующем спринте (безопасное окно)
+Downstream модели: models/staging/stg_orders.sql, models/mart/orders_daily.sql (+ 10 других — список приложен)
+Уведомление стейкхолдеров: analytics команда должна обновить любые прямые SQL запросы к raw.orders
+```
+
+---
+
+## Example 2 — Non-breaking new column
+
+**EN:**
+```
+/schema-migration
+
+Change: add column acquisition_channel (VARCHAR(50), nullable) to raw.users
+Source: Fivetran CRM connector — new field available from 2024-09-01
+Breaking: NO — additive change; existing queries unaffected
+Migration steps:
+  1. Confirm Fivetran sync picks up new field (check schema in Fivetran UI)
+  2. Add column to stg_users.sql SELECT and schema.yml documentation
+  3. Add acquisition_channel to mart.user_cohorts grouping (new dimension)
+  4. Backfill: historical rows will be NULL (field not available before 2024-09-01)
+  5. Add dbt test: accepted_values(organic, paid_search, referral, social, direct, unknown)
+Downstream impact: mart.user_cohorts will have new column — notify BI team to add to dashboards
+```
+
+**RU:**
+```
+/schema-migration
+
+Изменение: добавление столбца acquisition_channel (VARCHAR(50), nullable) в raw.users
+Источник: Fivetran CRM коннектор — новое поле доступно с 2024-09-01
+Breaking: НЕТ — аддитивное изменение; существующие запросы не затронуты
+Шаги миграции:
+  1. Убедиться что Fivetran sync подхватывает новое поле (проверить схему в Fivetran UI)
+  2. Добавить acquisition_channel в SELECT stg_users.sql и документацию schema.yml
+  3. Добавить acquisition_channel в группировку mart.user_cohorts (новое измерение)
+  4. Бэкфилл: исторические строки будут NULL (поле недоступно до 2024-09-01)
+  5. Добавить dbt тест: accepted_values(organic, paid_search, referral, social, direct, unknown)
+Влияние на downstream: mart.user_cohorts получит новый столбец — уведомить BI команду для добавления в дашборды
+```
+
+---
+
+## Example 3 — Type change (breaking)
+
+**EN:**
+```
+/schema-migration
+
+Change: order_id column type VARCHAR(36) → BIGINT in raw.orders
+Reason: source system migrated from UUID to integer IDs
+Breaking: YES — all downstream models cast or join on order_id as string
+Strategy:
+  1. Add order_id_new BIGINT column alongside VARCHAR order_id
+  2. Populate order_id_new for new records; historical UUIDs map to NULL (no integer equivalent)
+  3. Update all downstream models to use order_id_new with COALESCE(order_id_new, order_id) during transition
+  4. After 30 days, rename order_id_new → order_id; archive old VARCHAR column
+Historical records: ~3M orders with UUID order_id — will retain VARCHAR; only new orders get BIGINT
+```
+
+**RU:**
+```
+/schema-migration
+
+Изменение: тип столбца order_id VARCHAR(36) → BIGINT в raw.orders
+Причина: исходная система перешла с UUID на целочисленные ID
+Breaking: ДА — все downstream модели приводят или джойнят order_id как строку
+Стратегия:
+  1. Добавить столбец order_id_new BIGINT рядом с VARCHAR order_id
+  2. Заполнить order_id_new для новых записей; исторические UUID маппируются в NULL (нет целочислового эквивалента)
+  3. Обновить все downstream модели для использования order_id_new с COALESCE(order_id_new, order_id) в период перехода
+  4. Через 30 дней, переименовать order_id_new → order_id; архивировать старый VARCHAR столбец
+Исторические записи: ~3M заказов с UUID order_id — сохранят VARCHAR; только новые заказы получат BIGINT
+```

package/areas/software/data-engineering/rules/data-governance.md

@@ -0,0 +1,11 @@
+# Rule: Data Governance
+
+**Priority**: P1 — Required before data is consumed by dashboards or downstream services.
+
+## Constraints
+
+1. **Table documentation**: Every warehouse table must have `description` and owner annotation.
+2. **Column documentation**: All columns with non-obvious meaning must be documented.
+3. **SLA declaration**: Every pipeline must declare its freshness SLA. Breach of SLA by > 2x must page data on-call.
+4. **Data classification**: Every table classified as: `PUBLIC` / `INTERNAL` / `CONFIDENTIAL` / `RESTRICTED`.
+5. **Deprecation policy**: Unused tables (no queries in 90 days) flagged; archived after 30-day notice.

package/areas/software/data-engineering/rules/pii-handling.md

@@ -0,0 +1,19 @@
+# Rule: PII Data Handling
+
+**Priority**: P0 — PII exposure is a regulatory incident.
+
+## PII Classification
+
+| Type | Examples | Treatment |
+|:---|:---|:---|
+| Direct identifiers | Full name, email, phone, SSN | Hash (SHA-256 + salt) or tokenize |
+| Quasi-identifiers | Date of birth, ZIP, gender | Generalize in analytics |
+| Sensitive attributes | Health, financial, political views | Column-level encryption + RBAC |
+| Behavioral data | Clickstream, location history | Aggregate only; row-level PII purged after 30 days |
+
+## Constraints
+
+1. **No PII in warehouse tables by default**: Analytical tables contain `user_id` (hashed/tokenized), never email or name.
+2. **Data minimization**: Collect only what is needed. Each new data source requires documented business justification.
+3. **Right to erasure**: User deletion propagates to all tables within 30 days.
+4. **Cross-border restrictions**: EU resident data cannot be stored in non-EU regions without SCCs.

package/areas/software/data-engineering/rules/pipeline-integrity.md

@@ -0,0 +1,11 @@
+# Rule: Pipeline Integrity
+
+**Priority**: P0 — Violated pipelines are halted; downstream consumers notified.
+
+## Constraints
+
+1. **Idempotency**: Every pipeline produces identical output given identical input, regardless of how many times it runs.
+2. **Exactly-once semantics**: Pipelines writing to sinks must implement deduplication. Preferred: natural keys + `INSERT OVERWRITE`.
+3. **Fail loudly**: Pipelines must fail explicitly on data quality violations. Silent data corruption is a P0 incident.
+4. **Lineage tracking**: Every table must have documented source lineage. "Orphan" tables eligible for deprecation after 30-day notice.
+5. **No direct production writes from development**: Never point dev/staging pipelines to production. Use environment variables; never hardcode targets.

package/areas/software/data-engineering/rules/schema-management.md

@@ -0,0 +1,21 @@
+# Rule: Schema Management
+
+**Priority**: P0 — Breaking changes cause immediate downstream failures.
+
+## Breaking Changes (require migration plan)
+
+- Renaming or dropping a column
+- Changing column data type to incompatible type
+- Adding NOT NULL column without default value
+- Changing partition keys
+
+## Safe Changes
+
+- Adding new nullable columns
+- New tables
+- New partitions
+
+## Constraints
+
+1. **Contract versioning**: Tables consumed by external systems versioned during migrations (`orders_v1`, `orders_v2`). Old version maintained ≥ 30 days.
+2. **Schema registry for streaming**: All Kafka topics must have schemas in Confluent Schema Registry or AWS Glue. Producers validate before publishing.

package/areas/software/data-engineering/skills/data-modeling/SKILL.md

@@ -0,0 +1,49 @@
+# Skill: Data Modeling
+
+## When to load
+
+When designing a warehouse schema, choosing between modeling approaches, or refactoring an existing model.
+
+## Approach Decision Tree
+
+```
+Primary consumer?
+  → BI tools + analysts: Kimball (dimensional)
+  → Data science + ML: Wide denormalized tables
+  → Multiple teams: Data Vault
+
+History tracking?
+  → Never/rarely: Type 1 SCD (overwrite)
+  → Track current + previous: Type 2 SCD (versioned rows)
+
+Scale?
+  → < 100 GB: Simple star schema
+  → 100 GB – 10 TB: Partitioned star schema
+  → > 10 TB: Data Vault or Lakehouse (Delta/Iceberg)
+```
+
+## dbt Layering (Medallion Architecture)
+
+```
+sources/       ← Raw data as-is from source systems
+staging/       ← Cleaned, renamed, typed. 1:1 with source tables.
+intermediate/  ← Business logic, joins. Not exposed directly.
+marts/         ← Dimensional models for specific use cases
+  ├── core/    ← fct_*, dim_*
+  └── finance/ ← rpt_*
+```
+
+## Fact Table Template
+
+```sql
+CREATE TABLE fct_orders (
+    order_key    BIGINT PRIMARY KEY,  -- surrogate key
+    order_id     VARCHAR NOT NULL,    -- natural key
+    user_key     BIGINT REFERENCES dim_users(user_key),
+    date_key     INT REFERENCES dim_date(date_key),
+    quantity     INT NOT NULL,
+    total_amount NUMERIC(10,2) NOT NULL,
+    loaded_at    TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
+    source_system VARCHAR DEFAULT 'orders-api'
+);
+```

package/areas/software/data-engineering/skills/dbt-patterns/SKILL.md

@@ -0,0 +1,43 @@
+# Skill: dbt Development Patterns
+
+## When to load
+
+When building dbt models, writing macros, or configuring materializations.
+
+## Materialization Strategy
+
+| Layer | Materialization | Why |
+|:---|:---|:---|
+| `staging/` | `view` | Always reflects source |
+| `intermediate/` | `ephemeral` | Reduce clutter |
+| `marts/` | `table` or `incremental` | Pre-computed for BI |
+
+## Incremental Model
+
+```sql
+{{
+    config(
+        materialized='incremental',
+        unique_key='order_id',
+        incremental_strategy='merge',
+        partition_by={'field': 'order_date', 'data_type': 'date'},
+    )
+}}
+
+SELECT order_id, user_id, order_date, total_amount
+FROM {{ ref('stg_orders') }}
+
+{% if is_incremental() %}
+    WHERE order_date >= (SELECT MAX(order_date) FROM {{ this }}) - INTERVAL '3 days'
+{% endif %}
+```
+
+## Audit Columns Macro
+
+```sql
+{% macro audit_columns() %}
+    CURRENT_TIMESTAMP AS loaded_at,
+    '{{ invocation_id }}' AS dbt_invocation_id,
+    '{{ this.name }}' AS dbt_model
+{% endmacro %}
+```

package/areas/software/data-engineering/skills/lineage-governance/SKILL.md

@@ -0,0 +1,38 @@
+# Skill: Data Lineage & Governance
+
+## When to load
+
+When tracing data origins, assessing impact of schema changes, or managing data catalog.
+
+## Lineage in dbt
+
+```
+dbt manifest.json contains full lineage graph.
+Use: dbt ls --select +model_name (upstream)
+     dbt ls --select model_name+ (downstream)
+```
+
+## Impact Assessment for Column Change
+
+```
+Before renaming/dropping a column:
+1. dbt ls --select model_name+ → list all downstream models
+2. Check dashboards/BI tools connected to those models
+3. Check ML feature pipelines consuming the column
+4. Estimate blast radius: N models, M dashboards affected
+
+Migration approach for breaking changes:
+Phase 1: Add new column alongside old column
+Phase 2: Migrate downstream consumers to new column (coordinate with owners)
+Phase 3: Mark old column deprecated in YAML docs
+Phase 4 (after 30 days): Drop old column
+```
+
+## Data Catalog Standards
+
+Every table in the warehouse must have:
+- `description`: what the table represents (grain, one sentence)
+- `owner`: team or person responsible
+- `data_classification`: PUBLIC / INTERNAL / CONFIDENTIAL / RESTRICTED
+- `sla_freshness`: expected update frequency
+- Column descriptions for all non-obvious fields

package/areas/software/data-engineering/skills/orchestration/SKILL.md

@@ -0,0 +1,35 @@
+# Skill: Pipeline Orchestration (Airflow)
+
+## When to load
+
+When designing DAGs, debugging pipeline failures, or configuring retries.
+
+## DAG Template
+
+```python
+with DAG(
+    dag_id="orders_pipeline",
+    default_args={
+        "owner": "data-platform",
+        "retries": 3,
+        "retry_delay": timedelta(minutes=5),
+        "retry_exponential_backoff": True,
+        "email_on_failure": True,
+    },
+    schedule="0 4 * * *",
+    catchup=False,          # ← Never True; causes backfill avalanche
+    max_active_runs=1,      # Prevent concurrent runs
+) as dag:
+    ...
+```
+
+## Idempotent Task Pattern
+
+```python
+def load_orders(execution_date: str, **context):
+    """Safe to retry: DELETE + INSERT on target partition."""
+    partition = execution_date[:10]
+    with warehouse.connect() as conn:
+        conn.execute(f"DELETE FROM stg_orders WHERE order_date = '{partition}'")
+        conn.execute(f"INSERT INTO stg_orders SELECT * FROM raw_orders WHERE DATE(created_at) = '{partition}'")
+```

package/areas/software/data-engineering/skills/quality-checks/SKILL.md

@@ -0,0 +1,50 @@
+# Skill: Data Quality Checks
+
+## When to load
+
+When adding tests to dbt models, implementing data validation, or investigating quality incidents.
+
+## dbt Test Taxonomy
+
+```yaml
+models:
+  - name: fct_orders
+    columns:
+      - name: order_key
+        tests: [unique, not_null]
+      - name: user_key
+        tests:
+          - not_null
+          - relationships:
+              to: ref('dim_users')
+              field: user_key
+      - name: total_amount
+        tests:
+          - not_null
+          - dbt_utils.expression_is_true:
+              expression: ">= 0"
+      - name: order_status
+        tests:
+          - accepted_values:
+              values: ['pending', 'processing', 'completed', 'cancelled']
+    tests:
+      - dbt_utils.recency:
+          datepart: hour
+          field: loaded_at
+          interval: 4
+```
+
+## Volume Anomaly Detection
+
+```sql
+-- Alert when daily row count deviates > 3σ from 30-day rolling average
+WITH stats AS (
+    SELECT
+        load_date, row_count,
+        AVG(row_count) OVER (ORDER BY load_date ROWS BETWEEN 29 PRECEDING AND 1 PRECEDING) AS rolling_avg,
+        STDDEV(row_count) OVER (ORDER BY load_date ROWS BETWEEN 29 PRECEDING AND 1 PRECEDING) AS rolling_std
+    FROM daily_counts
+)
+SELECT *, CASE WHEN ABS(row_count - rolling_avg) > 3 * rolling_std THEN 'ANOMALY' ELSE 'OK' END AS status
+FROM stats WHERE load_date = CURRENT_DATE - 1;
+```

package/areas/software/data-engineering/skills/sql-optimization/SKILL.md

@@ -0,0 +1,47 @@
+# Skill: SQL Optimization
+
+## When to load
+
+When writing complex queries, optimizing slow queries, designing indexes, or reviewing query performance.
+
+## Core Patterns
+
+```sql
+-- ✅ Column projection — never SELECT *
+SELECT user_id, created_at, total_amount FROM orders WHERE created_at >= '2026-01-01';
+
+-- ✅ Partition pruning — filter on partition column first
+SELECT user_id, total_amount
+FROM orders
+WHERE order_date = '2026-01-15'  -- partition filter first
+  AND status = 'completed';
+
+-- ❌ Function on indexed column defeats index
+WHERE DATE(created_at) = '2026-01-15'
+-- ✅ Range comparison preserves index
+WHERE created_at >= '2026-01-15' AND created_at < '2026-01-16'
+```
+
+## Window Functions (prefer over self-joins)
+
+```sql
+SELECT
+    user_id, order_date, amount,
+    SUM(amount) OVER (
+        PARTITION BY user_id ORDER BY order_date
+        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
+    ) AS cumulative_amount,
+    ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_date DESC) AS recency_rank
+FROM orders;
+```
+
+## Snowflake-Specific
+
+```sql
+-- Cluster keys on large tables (> 1 TB)
+ALTER TABLE orders CLUSTER BY (order_date, status);
+
+-- COPY INTO for bulk loads — never row-by-row INSERT
+COPY INTO orders FROM @my_stage/orders/
+FILE_FORMAT = (TYPE = PARQUET) MATCH_BY_COLUMN_NAME = CASE_INSENSITIVE;
+```

package/areas/software/data-engineering/skills/streaming-patterns/SKILL.md

@@ -0,0 +1,48 @@
+# Skill: Streaming Data Patterns
+
+## When to load
+
+When designing Kafka consumers/producers or implementing real-time pipelines.
+
+## Producer Best Practices
+
+```python
+producer = Producer({
+    "bootstrap.servers": settings.KAFKA_BROKERS,
+    "acks": "all",               # Wait for all replicas
+    "retries": 5,
+    "enable.idempotence": True,  # Exactly-once delivery
+    "compression.type": "snappy",
+})
+```
+
+## Consumer Pattern
+
+```python
+consumer = Consumer({
+    "group.id": "order-processor-v1",  # Version when changing logic
+    "auto.offset.reset": "earliest",
+    "enable.auto.commit": False,        # Manual commit: only after successful processing
+})
+
+msg = consumer.poll(timeout=1.0)
+try:
+    process(deserialize(msg.value()))
+    consumer.commit(msg)  # Commit only after success
+except ProcessingError as e:
+    publish_to_dlq(msg, e)  # Dead-letter, don't block partition
+    consumer.commit(msg)
+```
+
+## Dead Letter Queue
+
+```json
+{
+  "original_topic": "orders.created.v1",
+  "original_offset": 12345,
+  "original_payload": "...",
+  "error_message": "Deserialization failed",
+  "error_timestamp": "2026-02-16T10:30:00Z",
+  "retry_count": 3
+}
+```

package/areas/software/data-engineering/workflows/backfill-data.md

@@ -0,0 +1,59 @@
+---
+name: backfill-data
+type: workflow
+trigger: /backfill-data
+description: Safely reprocess historical data without disrupting live pipelines or downstream consumers.
+inputs:
+  - model_name
+  - date_range
+outputs:
+  - backfilled_model
+  - validation_report
+roles:
+  - developer
+  - qa
+  - team-lead
+execution:
+  initiator: developer
+related-rules:
+  - pipeline-integrity.md
+  - data-governance.md
+uses-skills:
+  - orchestration
+  - quality-checks
+quality-gates:
+  - single-partition validated before full run
+  - no duplicates on unique key post-backfill
+  - downstream consumers notified
+---
+
+## Steps
+
+### 1. Impact Assessment — `@developer`
+- **Input:** model name, date range
+- **Actions:** identify all downstream models depending on target; estimate row count and processing time; check if model consumed by real-time dashboards or SLA-critical flows; calculate optimal batch size to avoid OOM; estimate compute cost (Snowflake credits, BigQuery bytes)
+- **Output:** impact assessment note with batch plan and cost estimate
+- **Done when:** `@team-lead` approves plan; cost within budget
+
+### 2. Dry Run — `@qa`
+- **Input:** approved batch plan
+- **Actions:** run backfill on single-day partition first; compare row counts with source; check for duplicates on unique key
+- **Output:** dry-run validation results
+- **Done when:** single partition matches source with no duplicates
+
+### 3. Execute Backfill — `@developer`
+- **Input:** validated dry run
+- **Actions:** run in off-peak hours; log progress every N batches; on failure: report which partition failed — do not retry blindly
+  - small models: `dbt run --select <model> --full-refresh`
+  - large ranges: chunked SQL with progress logging by month
+- **Output:** backfill complete; progress log
+- **Done when:** all partitions processed without errors
+
+### 4. Post-Backfill Validation — `@qa`
+- **Input:** backfilled model
+- **Actions:** run dbt tests on backfilled model; compare key metrics before/after; verify no duplicates; notify downstream consumers that backfill is complete
+- **Output:** `validation_report.md` — row counts, metric comparison, dbt test results
+- **Done when:** all tests pass; metrics match expected; consumers notified
+
+## Exit
+Validated backfill + notified consumers + `@team-lead` sign-off = backfill complete.

package/areas/software/data-engineering/workflows/data-quality-incident.md

@@ -0,0 +1,64 @@
+---
+name: data-quality-incident
+type: workflow
+trigger: /data-quality-incident
+description: Triage and resolve a data quality issue with quarantine, root cause analysis, and prevention.
+inputs:
+  - model_name
+  - incident_type
+outputs:
+  - remediated_model
+  - postmortem
+roles:
+  - qa
+  - developer
+  - team-lead
+execution:
+  initiator: qa
+related-rules:
+  - pipeline-integrity.md
+  - data-governance.md
+  - pii-handling.md
+uses-skills:
+  - quality-checks
+  - lineage-governance
+quality-gates:
+  - affected partitions quarantined before fix
+  - root cause identified and documented
+  - monitoring rule added to prevent recurrence
+---
+
+## Steps
+
+### 1. Scope & Triage — `@qa`
+- **Input:** incident alert or report
+- **Actions:** check row count and freshness on affected model; compare to expected values from monitoring baselines; identify when anomaly started and which partitions are affected; classify type: duplicate / missing / wrong_values / sla_breach
+- **Output:** incident scope note — affected partitions, anomaly window, classification
+- **Done when:** scope confirmed; `@team-lead` briefed
+
+### 2. Quarantine — `@developer`
+- **Input:** affected partitions list
+- **Actions:** tag affected partitions as `data_quality=SUSPECT`; alert downstream consumers (BI, ML teams) to not use affected data
+- **Output:** quarantine applied; consumers notified
+- **Done when:** affected data marked; no new consumers reading suspect partitions
+
+### 3. Root Cause Isolation — `@qa` + `@developer`
+- **Input:** quarantined incident
+- **Actions:** check in order — (a) source data: correct in raw? compare raw vs. staged; (b) pipeline logic: recent code changes? `git log`; (c) schema change: upstream registry diff; (d) infrastructure: warehouse outage or partial run
+- **Output:** root cause identified and documented
+- **Done when:** single root cause confirmed; not multiple competing hypotheses
+
+### 4. Remediation — `@developer`
+- **Input:** confirmed root cause
+- **Actions:** fix root cause in pipeline code; re-run pipeline via `/backfill-data` for affected window; lift quarantine tag after validation passes
+- **Output:** remediated model; quarantine lifted
+- **Done when:** `/backfill-data` validation passes; model clean
+
+### 5. Post-Incident — `@team-lead` + `@qa`
+- **Input:** remediated incident
+- **Actions:** add monitoring rule to catch this pattern earlier; update dbt tests to prevent regression; write postmortem: `.data/incidents/<date>-<model>-incident.md`
+- **Output:** postmortem; monitoring updated; dbt tests updated
+- **Done when:** postmortem reviewed; prevention measures in place
+
+## Exit
+Clean model + postmortem published + prevention measures added = incident closed.

package/areas/software/data-engineering/workflows/lineage-trace.md

@@ -0,0 +1,56 @@
+---
+name: lineage-trace
+type: workflow
+trigger: /lineage-trace
+description: Visualize full data lineage and assess blast radius of a column or table change before executing it.
+inputs:
+  - target_column_or_table
+  - direction
+outputs:
+  - lineage_diagram
+  - impact_report
+roles:
+  - developer
+  - team-lead
+execution:
+  initiator: developer
+related-rules:
+  - data-governance.md
+  - schema-management.md
+uses-skills:
+  - lineage-governance
+  - data-modeling
+quality-gates:
+  - all downstream models and dashboards identified
+  - SLA-critical models in blast radius explicitly flagged
+  - migration checklist produced for breaking changes
+---
+
+## Steps
+
+### 1. Parse Target — `@developer`
+- **Input:** target column or table, direction (upstream / downstream / both)
+- **Actions:** identify table and optional column in warehouse catalog; load dbt `manifest.json` for lineage graph
+- **Output:** confirmed target node in lineage graph
+- **Done when:** target resolved; manifest loaded
+
+### 2. Trace Lineage — `@developer`
+- **Input:** lineage graph
+- **Actions:** upstream: walk `ref()` dependencies to source tables; downstream: walk all models that `ref()` the target; for column-level: identify all downstream `SELECT` statements referencing the column
+- **Output:** upstream and downstream node lists
+- **Done when:** full graph traversal complete
+
+### 3. Impact Assessment — `@team-lead`
+- **Input:** node lists
+- **Actions:** for rename/drop: count downstream models and dashboards referencing the column; flag SLA-critical models; estimate migration effort (S/M/L)
+- **Output:** impact summary — N models, M dashboards, criticality flags
+- **Done when:** all impacted assets identified; `@team-lead` reviewed
+
+### 4. Generate Report — `@developer`
+- **Input:** impact assessment
+- **Actions:** produce Mermaid diagram of lineage graph; write summary: affected models count, dashboard list, SLA-critical flags; produce migration checklist for breaking changes; for breaking: propose versioned approach if needed
+- **Output:** `lineage_report.md` with diagram, summary, and checklist
+- **Done when:** report reviewed and ready to share with affected owners
+
+## Exit
+Published lineage report + migration checklist = ready to plan the change safely.