ml-feature-engineering
Skill1 starsChanged 38 days agoMITView on GitHub
Designs ML features with leakage-safe pipelines, correct categorical encoding by cardinality, numeric transforms, and validation that a feature earns its place. Use when someone asks "how should I encode this high-cardinality column", "why does my model score great offline and fail in production", "what features should I build from this table", or "should I scale these inputs". Do NOT use for building the serving infrastructure that stores and versions features across models - use feature-store-design instead; for detecting when live feature distributions shift after deployment - use data-drift-monitor instead; for initial dataset exploration and profiling - use eda-playbook instead.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- SkillMedev/data-engineering-pipelineword for word, first seen Oct 5, 2026
- SkillMedev/ai-engineer-toolkitword for word, first seen Oct 5, 2026
Other versions2 projects use a version of this.
Word for word · 2
- SkillMedev/ai-engineer-toolkit★ 0100% same
- SkillMedev/data-engineering-pipeline★ 0100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository6 other files it gives its agents.
- data-drift-monitorSkill
- eda-playbookSkill
- experiment-trackingSkill
- feature-store-designSkill
- model-card-writerSkill
- model-evaluation-reportSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
14 rules. About 0 are common, 13 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈13
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 29
Never use information from after the prediction time.
- Distinctive: line 45
If any transform lives outside the pipeline, assume it leaks until proven otherwise.
- Distinctive: line 72
Add a binary missing-indicator before imputing when the null rate exceeds ~5% - missingness is often informative.
- Distinctive: line 74
Avoid mean imputation on skewed data.
- Distinctive: line 79
Remove near-constant features (over ~99% a single value) and one of any pair with |correlation| > 0.95.
- Distinctive: line 80
Use permutation importance or SHAP rather than raw model importances, which inflate high-cardinality features.
- Distinctive: line 82
Keep a feature catalog documenting source, transformation, and refresh cadence.
- Distinctive: line 115
Do not fit any transformer outside the cross-validation loop.
- Distinctive: line 116
Do not target-encode with in-fold means - it is leakage even when the code looks innocent.
- Very specific: line 117
Do not scale features for tree ensembles or skip scaling for linear/kNN/neural models.
- Distinctive: line 118
Do not trust raw impurity-based importances.
- Distinctive: line 119
Do not keep a feature because it is clever.
- Distinctive: line 123
Every transform is inside a Pipeline/ColumnTransformer and fit on training folds only.
- Distinctive: line 124
Every feature has a documented answer to "is this value knowable at prediction time?"
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Feature Engineering
Most "amazing offline, useless in production" models are not modeling failures - they are leakage failures introduced during feature engineering. This skill builds features that improve cross-validated performance without smuggling the target into the inputs, and rejects features that only look good because they cheated.
Operating procedure
Leakage prevention comes first because every later step (encoding, aggregation, imputation) is a leakage opportunity; validation comes last because a feature that does not move the cross-validated metric does not ship.
Step 1: Gather inputs
Collect before writing transforms; label unknowns as guesses.
- Prediction task and the exact prediction time: what is known at the moment the model must predict? Everything else is off-limits.
- Target definition and how it was produced - features derived from the same process as the label are proxy-leakage suspects.
- Data shape: row count, column list with dtypes, entity keys, and whether rows have a time dimension.
- Model family (linear, tree ensemble, neural) - it determines which transforms are necessary and which are wasted work.
- Serving constraints: will these features be computable at inference time with the same code and latency budget?
Step 2: Lock the leakage rules
- Fit all transformers (scalers, encoders, imputers) on the training fold only, then apply to validation and test.
- Never use information from after the prediction time.
- Exclude features that are proxies for the label or only known after the outcome (e.g. "account_closed_reason" in a churn model).
- For time series, split by time and never shuffle.
Enforce mechanically with scikit-learn Pipelines and ColumnTransformer so fitting always happens inside cross-validation:
from sklearn.pipeline import Pipeline
from sklearn.compose import ColumnTransformer
pre = ColumnTransformer([
("num", StandardScaler(), num_cols),
("cat", OneHotEncoder(handle_unknown="ignore"), cat_cols),
])
model = Pipeline([("pre", pre), ("clf", GradientBoostingClassifier())])If any transform lives outside the pipeline, assume it leaks until proven otherwise.
Step 3: Encode categoricals by cardinality
Pick the encoder from the category count - this is a lookup, not a debate:
- Up to ~15 categories: one-hot. Safe for any model.
- ~15-50 categories: one-hot still works for tree ensembles; for linear models watch the coefficient count.
- 50+ categories: target/mean encoding, computed strictly with out-of-fold means - in-fold target encoding is the single most common leakage bug in tabular ML. Add smoothing toward the global mean for categories with fewer than ~20 rows.
- 10,000+ categories (user IDs, URLs): hashing encoder when memory matters, or entity embeddings.
- Ordinal encoding only when categories have a true order (S < M < L), never as a memory shortcut.
Step 4: Transform numerics
- Scale (standardize or min-max) for distance- and gradient-based models; tree ensembles do not need it - skip the work.
- Apply log or Box-Cox to skewed positive features; a rule of thumb trigger is |skewness| > 1.
- Bin into quantiles when the relationship is non-monotonic and the model is linear.
Step 5: Build derived features
- Ratios and differences encode domain meaning cheaply: price per unit, days since last event.
- Polynomial or explicit interaction terms help linear models capture combined effects.
- Group-by aggregations (mean, count, std per entity) are the highest-value tabular features - and must be computed out-of-fold or over past-only windows, or they leak.
- Datetime: extract hour, day of week, month, is_weekend, plus cyclical sine/cosine encodings for periodic values, and elapsed-time features like days since signup.
Step 6: Handle missing values
- Add a binary missing-indicator before imputing when the null rate exceeds ~5% - missingness is often informative.
- Impute numerics with median, categoricals with a dedicated "missing" category.
- Avoid mean imputation on skewed data.
- A feature over ~60% missing rarely earns its place unless the missingness itself predicts; test the indicator alone first.
Step 7: Select and validate
- Remove near-constant features (over ~99% a single value) and one of any pair with |correlation| > 0.95.
- Use permutation importance or SHAP rather than raw model importances, which inflate high-cardinality features.
- A feature ships only if it improves the cross-validated metric, not training fit. Suspicious rule: any single new feature that jumps AUC by more than ~0.05 is a leakage suspect first and a triumph second - audit its availability at prediction time before celebrating.
- Keep a feature catalog documenting source, transformation, and refresh cadence; when features are shared across models, graduate to feature-store-design.
Worked artifact: leakage contrast pair
Bad - target encoding fit on the full dataset before the split:
means = df.groupby("merchant_id")["is_fraud"].mean() # sees test-set labels
df["merchant_te"] = df["merchant_id"].map(means)
X_train, X_test = train_test_split(df) # too late: already leakedGood - out-of-fold target encoding, so each row's encoding never saw its own label:
from sklearn.model_selection import KFold
df["merchant_te"] = np.nan
for tr_idx, val_idx in KFold(5, shuffle=True, random_state=0).split(df):
means = df.iloc[tr_idx].groupby("merchant_id")["is_fraud"].mean()
global_mean = df.iloc[tr_idx]["is_fraud"].mean()
df.loc[df.index[val_idx], "merchant_te"] = (
df.iloc[val_idx]["merchant_id"].map(means).fillna(global_mean)
)The bad version typically shows a large offline lift that evaporates in production; the good version shows a smaller, honest lift that survives.
Deliverable
Produce a feature specification containing: the prediction-time definition, the feature list with source, transform, encoder choice and rationale, the leakage audit (how each feature is available at prediction time), imputation and indicator decisions, and the cross-validated before/after metric for each added feature group.
Do NOT
- Do not fit any transformer outside the cross-validation loop; the pipeline is the guardrail, not a style preference.
- Do not target-encode with in-fold means - it is leakage even when the code looks innocent.
- Do not scale features for tree ensembles or skip scaling for linear/kNN/neural models; match transform to model family.
- Do not trust raw impurity-based importances; they overrate high-cardinality columns.
- Do not keep a feature because it is clever; keep it because the cross-validated metric moved.
Quality bar
- Every transform is inside a Pipeline/ColumnTransformer and fit on training folds only.
- Every feature has a documented answer to "is this value knowable at prediction time?"
- Encoder choices follow the cardinality ladder, with out-of-fold means for target encoding.
- Time-dimensioned data uses time-based splits.
- Each shipped feature shows a cross-validated improvement, and any outsized single-feature jump has been leakage-audited.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

