feature-store-and-ml-data-pipelines

Name: feature-store-and-ml-data-pipelines
Author: vaquarkhan

19stars4forks

How to install feature-store-and-ml-data-pipelines?

vaquarkhan/data-engineering-agent-skills/feature-store-and-ml-data-pipelines

$npx -y skills add vaquarkhan/data-engineering-agent-skills --skill feature-store-and-ml-data-pipelines

Installs into the current project.

Summary

Guides agents through machine-learning data pipelines and feature serving workflows. Use when designing feature generation, offline and online consistency, training-serving parity, point-in-time correctness, or ML-oriented data product contracts.

Files · 1

View on GitHub

SKILL.md

1	# Feature Store And ML Data Pipelines
2
3	## Overview
4
5	Use this skill when the platform must support model training and inference safely. It helps agents design feature generation, point-in-time correctness, serving parity, and operational contracts for ML-focused data products.
6
7	## When to Use
8
9	- building training datasets
10	- designing feature stores or reusable features
11	- supporting online and offline feature access
12	- preventing leakage and training-serving mismatch
13	- publishing model-ready data products
14
15	Do not treat feature pipelines as ordinary marts with different names. ML pipelines have different correctness risks.
16
17	## Workflow
18
19	1. Define the feature contract.
20	Include:
21	- entity key
22	- feature meaning
23	- update cadence
24	- online or offline use
25	- freshness expectation
26
27	2. Protect point-in-time correctness.
28	Training data must only include information available at prediction time.
29
30	3. Align offline and online logic.
31	Reuse definitions and validation wherever possible to prevent training-serving drift.
32
33	4. Define feature lifecycle and ownership.
34	Clarify:
35	- producer
36	- consumers
37	- deprecation path
38	- quality monitoring
39
40	5. Validate operational behavior.
41	Models break when stale or missing features silently propagate.
42
43	## Common Rationalizations
44
45	\| Rationalization \| Reality \|
46	\| --- \| --- \|
47	\| "We can use the latest value for training." \| That often introduces leakage and overstates model performance. \|
48	\| "Online parity is a model-team problem." \| Feature consistency is a data pipeline responsibility too. \|
49	\| "Features are internal, so contracts are unnecessary." \| Unclear feature meaning leads to misuse and drift. \|
50
51	## Red Flags
52
53	- no point-in-time logic is defined
54	- offline and online definitions diverge
55	- stale features are not monitored
56	- feature ownership is unclear
57
58	## Verification
59
60	- [ ] Feature meaning, keys, and freshness are documented
61	- [ ] Point-in-time correctness is protected
62	- [ ] Offline and online parity expectations are explicit
63	- [ ] Monitoring exists for stale, missing, or drifting features

People who liked this also viewed

6 picks

Type

feature-store-and-ml-data-pipelines

19stars4forks

View on GitHub

How to install feature-store-and-ml-data-pipelines?

vaquarkhan/data-engineering-agent-skills/feature-store-and-ml-data-pipelines

$npx -y skills add vaquarkhan/data-engineering-agent-skills --skill feature-store-and-ml-data-pipelines

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Feature Store And ML Data Pipelines
2
3	## Overview
4
5	Use this skill when the platform must support model training and inference safely. It helps agents design feature generation, point-in-time correctness, serving parity, and operational contracts for ML-focused data products.
6
7	## When to Use
8
9	- building training datasets
10	- designing feature stores or reusable features
11	- supporting online and offline feature access
12	- preventing leakage and training-serving mismatch
13	- publishing model-ready data products
14
15	Do not treat feature pipelines as ordinary marts with different names. ML pipelines have different correctness risks.
16
17	## Workflow
18
19	1. Define the feature contract.
20	Include:
21	- entity key
22	- feature meaning
23	- update cadence
24	- online or offline use
25	- freshness expectation
26
27	2. Protect point-in-time correctness.
28	Training data must only include information available at prediction time.
29
30	3. Align offline and online logic.
31	Reuse definitions and validation wherever possible to prevent training-serving drift.
32
33	4. Define feature lifecycle and ownership.
34	Clarify:
35	- producer
36	- consumers
37	- deprecation path
38	- quality monitoring
39
40	5. Validate operational behavior.
41	Models break when stale or missing features silently propagate.
42
43	## Common Rationalizations
44
45	\| Rationalization \| Reality \|
46	\| --- \| --- \|
47	\| "We can use the latest value for training." \| That often introduces leakage and overstates model performance. \|
48	\| "Online parity is a model-team problem." \| Feature consistency is a data pipeline responsibility too. \|
49	\| "Features are internal, so contracts are unnecessary." \| Unclear feature meaning leads to misuse and drift. \|
50
51	## Red Flags
52
53	- no point-in-time logic is defined
54	- offline and online definitions diverge
55	- stale features are not monitored
56	- feature ownership is unclear
57
58	## Verification
59
60	- [ ] Feature meaning, keys, and freshness are documented
61	- [ ] Point-in-time correctness is protected
62	- [ ] Offline and online parity expectations are explicit
63	- [ ] Monitoring exists for stale, missing, or drifting features

People who liked this also viewed

6 picks

Type