The same pipeline → skill move that built this product, packaged for anyone. Eight composable data roles — from raw files to a governed semantic layer, a served model, and a deployment — that you install into Claude Code (or drive from any agent) and run over your own data.
/plugin
commands). stdlib-only · no venv · your local model is the engine.Pick any subset of roles, in any order. A dependency resolver figures out what each needs and synthesizes the rest — ask for just the Analyst on a folder of CSVs and it builds the medallion first.
Each role is a real stage — a small, readable program plus a plain-language persona that carries the craft. Read top to bottom and you have covered the entire arc of working with data.
The whole of data modeling lives in roles 1–3. The Data Architect does conceptual & logical modeling (entities, types, keys); the Data Engineer does physical & dimensional modeling (the medallion and the star schema); the Data Designer does semantic/metric modeling (the governed definition layer). Nothing in the modeling discipline — normalization, grain, facts & conformed dimensions, additivity, lineage — is left out.
| Role | What it does — in detail | Output |
|---|---|---|
| 1 Data Architect | Ingests heterogeneous raw sources — CSV, TSV, JSON/NDJSON, XML, XLSX, and (via optional adapters) PDF and images through OCR — and reverse-engineers a logical model from them: inferring column data types, primary/candidate keys, cardinality, null-rates and quality profiles, and candidate dimensions. It lands everything as typed bronze tables with a source catalog, and flags PII/sensitive columns at the door. This is the conceptual→logical modeling seat: deciding what the entities are, how they are keyed, and what is trustworthy, before a single row moves downstream. | bronze + catalog |
| 2 Data Engineer | Runs the medallion transformation and materializes the dimensional (physical) model. Bronze → silver (cleaning, de-duplication, type-conforming, business-rule fixes) → gold, where it builds a star schema: aggregated fact tables at a declared grain plus conformed dimension tables, indexed for query. Crucially, every summed measure in gold is reconciled back to the raw fact, so the numbers are provably correct, and full lineage (file → bronze → silver → gold) is captured. This is Kimball-style dimensional modeling made executable — not a diagram, a materialized, auditable warehouse. | silver gold + lineage |
| 3 Data Designer | Builds the governed semantic layer — the metric model that sits above gold (the layer dbt-metrics, LookML and Cube occupy). Each metric is defined once in a DSL — its measure or numerator/denominator, grain, dimensions, unit, owner and version — then compiled and dry-run against gold for conformance. The built-in re-aggregation guard enforces additivity correctness: an additive measure may roll up by summing; a ratio is recomputed from its components; a distinct-count is routed to a Theta/HLL sketch — never silently summed up a grain. Semantic/metric modeling with governance baked in. | semantic + conformance |
| 4 Data Analyst | Translates natural-language business questions into governed SQL over gold and the semantic layer — detecting the metric, breakdown dimensions, filters and rankings — and returns reports, tables and charts. Every answer carries a receipt: the metric definition, owner, version, the exact SQL, and lineage, so any number is traceable end to end. The guard is honored automatically, so a ratio is recomputed, never mis-summed. | reports + charts |
| 5 BI Engineer branch | Stands up a refreshing, role-scoped BI layer off gold: KPI panels and dimensional breakdowns materialized from the semantic layer, served as a self-contained dashboard. RBAC is enforced at the edge (admin / analyst / leadership / viewer), so sensitive metrics — finance, payments — are withheld from the wrong roles. Re-running the stage refreshes it. This is the served BI product on top of the model. | dashboard |
| 6 Data Scientist branch | Trains and honestly evaluates a predictive model on gold — one-hot-encoding dimensions, holding out a test split, reporting real R²/RMSE/MAE and the fitted coefficients. This is the statistical-modeling seat, deliberately distinct from data modeling: it turns the governed data into forecasts and decision support, with the model itself emitted as a portable, inspectable artifact. | model + eval |
| 7 ML Engineer branch | Productionizes the trained model: packages it with its schema and version into a self-contained, servable
prediction API — /predict, /health, and a Prometheus /metrics
endpoint — deployable anywhere with no framework or venv. The MLOps seat: from a fitted model to a running,
versioned, monitorable service. |
service |
| 8 Data SRE plane | The platform plane. It wraps any deployable — the model API, the BI dashboard, or the pipeline itself
— into Kubernetes manifests plus horizontal autoscaling (HPA), Prometheus observability (a ServiceMonitor
scraping the real /metrics), and SLO alerting (availability, error-rate). This is where the
whole lifecycle becomes a running, monitored, reliable system at scale. |
deployment |
This isn't a black box — it's a kit. Each role is an independent stage: a small, readable script plus a plain-markdown persona that carries the judgment. So you bring in exactly the roles your use case needs and adapt each one to your domain and data.
Install the plugin (npx data-team-skill or
/plugin install) and run /data-team:run — it asks where your data is, which roles you
want, and what to answer. The full team, one command.
The core is stdlib Python + markdown — no framework, no
venv. So Cursor, Codex, another coding agent, or you in a plain terminal can drive an individual stage:
python3 run_pipeline.py --stages engineer,designer …
Each stage's persona (personas/<role>/*.md) is
editable prose — add your cleaning rules, your metric definitions, your SLOs. The mechanical core stays
deterministic; you tune the reasoning.
Want only Architect → Engineer → Analyst? Or just the
ML branch on an existing gold layer? Pass --stages and bring-your-own artifacts; the
resolver keeps it coherent.
In short: install it once, then lift out the roles you need, rewire them to your data, and let your agent of choice run them. The eight roles are a starting team — not a cage.
Zip the folder and the data, definitions, reports, model, and lineage all travel together.
http.server model API.AI does not scale on model-builders alone. It scales on data-aware people in every function — the domain experts who can structure, annotate, and reason about the data their work already generates.
By widely cited workforce estimates, the scarce resource for the AI era isn't only data scientists — it is the far larger population of domain experts, analysts and operators, across every industry, who understand how data is shaped and moved. Whoever is closest to the data — irrespective of their background — increasingly needs to be fluent in the pipeline that turns it into decisions.
Upskilling and training in data-pipeline awareness — across every vertical of an organization — is the need of the hour.
And that training has to be hands-on and universal: platform-agnostic, model-agnostic, and hardware-agnostic. This is exactly where the Data-Team Skill fits. Data annotation, data structuring, and every stage of the data lifecycle revolve around the same eight pillars this pipeline makes concrete — ingest, model, define, analyze, visualize, predict, serve, operate. A marketer, an ops lead, a clinician, or a domain expert can learn the whole arc by running it on their own data — on any platform, any model, any hardware.
Not a course about pipelines — the pipeline itself, as the classroom. That is how an organization builds data literacy at scale, and how the workforce keeps pace with AI.