Data engineering · inspect by default

/data-lineage

Trace field origins and transformations

Use to find where a field or metric comes from across transformations; trace follows one execution instance.

Make it your own.

In Claude Code, use the slash command and add your context. In Codex, select data-lineage from the just-vibe skill picker, then send the same brief.

Version 0.11.0 also supports /jv data-lineage, /just-vibe data-lineage and /jv:data-lineage in Claude. See shortcut setup and context examples.

Example · inspect
/just-vibe:data-lineage Trace invoice_total through the transforms and source columns.
edge · inspect
/just-vibe:data-lineage Trace a revenue metric through currency conversion and filtered joins.
blocked · inspect
/just-vibe:data-lineage Map lineage from partial job definitions without upstream access.

What the agent does

  1. Follow field expressions through jobs, views, joins, filters, aggregations and versioned jobs.
  2. Record grain changes, lossy transformations, versions and ownership at each boundary, and mark opaque external steps.

Inputs

  • field/table/report and source/transformation definitions.

Optional context: scope, references, constraints, successCriteria, environment, mode, budget.

Scope

Reads
Origins, transformations, joins, filters, and downstream dependencies for the target data.
Writes
No source changes in inspect/plan. Save only requested planning artifacts. data-pipeline or fix applies an accepted change.
Mode
Inspect; field/table/report and source/transformation definitions.
Prerequisites
Data source/version, schema/semantics, transformation code, permitted sampling scope, and storage/compute budget. Prefer aggregates and redacted samples; never upload datasets to external services implicitly. Record time zones and snapshot identity for reproducibility.

Expected output

  • Field-level lineage graph or table with transformations, versions, owners, evidence links, opaque boundaries and gaps.

How the work is checked

  • Derived aggregates include filter/join semantics; an opaque imported table is shown as an unknown boundary rather than assigned invented provenance.

When to stop or clarify

  • Cap expansion at the requested scope. Documentation-only lineage is labeled separately from code-verified lineage.

Handling missing context

Infer
Inspect schema, source snapshot, transformation code, grain, time zones and permitted sample scope.
Assume
Use bounded synthetic or supplied samples when full data is unavailable; keep unknown values distinct from zero.
Ask
Resolve ambiguous entity/grain/time semantics before reconciliation or backfill; obtain missing data/compute limits only for the dependent scan or execution.

Technical guidance

Evidence
Read SQL, transformation code, field mappings, job versions and execution/snapshot metadata.
Method
Trace each derived field to source fields and transformations, marking dynamic or external edges unresolved.
Pitfall
An import graph or column-name match does not prove runtime provenance.
Check
Walk one record and one corrected version through the path and verify the documented transform against actual code and run identity.

Situational decisions

When an imported dataset has opaque provenance: Stop confirmed lineage at that source and request its producer contract rather than assigning an invented origin.

The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.

Keep exploring