agentleFS
OpenCovenOpenCoven/coven/skills/ml-engineer/SKILL.md

ml-engineer

Skill75 starsChanged 4 months agoMITView on GitHub

Build production ML systems: model training pipelines, serving infrastructure, performance optimization, and automated retraining. Use when: (1) designing or building ML pipelines (data validation → training → deployment), (2) optimizing model training (hyperparameter search, distributed training, checkpointing), (3) deploying models to production (REST/gRPC endpoints, batch/stream processing, canary releases), (4) setting up ML monitoring (prediction drift, feature drift, performance decay), (5) implementing feature engineering or feature stores, (6) automating retraining triggers, (7) debugging model performance or serving latency issues. Triggers on: ML pipeline, model training, model serving, feature engineering, hyperparameter tuning, model deployment, inference optimization, model monitoring, MLOps, retraining.

9 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

1 rule. 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 8 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Hyperparameter optimization: Use Optuna (Bayesian) by default.

    line 52

“Common” is measured: kept by at least 6 in 10 of the 8 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

ML Engineer

Build and operate production ML systems across the full lifecycle: data → features → training → validation → deployment → monitoring → retraining.

Core Workflow

1. System Analysis

Before building anything:

  1. Define the problem — classification, regression, ranking, generation, etc.
  2. Assess data — volume, quality, drift patterns, labeling status
  3. Set targets — accuracy, latency (<50ms inference), training time (<4h), cost ceiling
  4. Map infrastructure — compute (GPU/CPU), storage, orchestration, serving platform
  5. Choose deployment strategy — real-time, batch, streaming, edge
  6. Plan monitoring — what metrics, what thresholds, who gets paged

2. Pipeline Development

Build modular, versioned pipelines. Each stage should be independently testable and retriable.

Data Validation → Feature Engineering → Training → Validation → Deployment → Monitoring
      ↑                                                                          |
      └──────────────────── Retraining Trigger ←──────────────────────────────────┘

Pipeline principles:

  • Data validation FIRST — catch schema drift, missing values, distribution shifts before training
  • Version everything: data, features, models, configs, code
  • Each stage writes artifacts to a versioned store (MLflow, DVC, W&B)
  • Fail fast with clear error messages; never silently produce bad models

See references/pipelines.md for stage-by-stage implementation patterns.

3. Training & Optimization

Select the right approach based on complexity:

Data SizeComplexityApproach
Small (<10K)LowScikit-learn, XGBoost, single-machine
Medium (10K-1M)MediumPyTorch/TF, single GPU, Optuna HPO
Large (1M+)HighDistributed training (Ray, DeepSpeed), transfer learning
Huge (100M+)Very highMulti-node, model sharding, mixed precision

Hyperparameter optimization: Use Optuna (Bayesian) by default. Grid search only for ≤3 params with known ranges. Always set a trial budget and time ceiling.

Validation: k-fold cross-validation for small data, holdout + temporal split for time-series, stratified for imbalanced classes.

See references/training.md for distributed training, transfer learning, and advanced optimization patterns.

4. Deployment

Match deployment pattern to use case:

PatternWhenTrade-off
Blue-greenZero-downtime upgrades2x infrastructure cost
CanaryGradual rollout with safetySlower full deployment
ShadowTest new model on live traffic without servingExtra compute
A/B testCompare models on real usersNeeds traffic splitting infra
BatchPeriodic predictions on stored dataHigher latency, lower cost
Real-timeSub-100ms predictionsRequires serving infrastructure

Serving checklist:

  • Model serialized (ONNX, TorchScript, SavedModel)
  • Inference endpoint tested (load test, edge cases)
  • Health check endpoint active
  • Fallback model configured
  • Auto-scaling rules set
  • Request/response logging enabled

See references/deployment.md for serving frameworks, scaling, and reliability patterns.

5. Monitoring & Retraining

Monitor these signals continuously:

SignalDetection MethodAction
Prediction driftPSI, KS test on output distributionAlert → investigate
Feature driftKS test per feature vs training distributionAlert → retrain if confirmed
Performance decayAccuracy/F1 on labeled sample drops >5%Trigger retraining
Data qualitySchema validation, null rate, outlier countBlock pipeline
Latency spikep95 > 2x baselineScale up or optimize

Retraining triggers:

  • Scheduled (weekly/monthly baseline)
  • Drift-triggered (automated when metrics cross threshold)
  • Manual (new labeled data, new features, architecture change)

See references/monitoring.md for drift detection implementations and alerting patterns.

Quick Reference — ML System Template

project/
├── data/
│   ├── raw/              # Immutable source data
│   ├── processed/        # Feature-engineered datasets
│   └── validation/       # Test sets, golden sets
├── features/
│   ├── pipelines/        # Feature transformation code
│   └── store/            # Feature store config
├── training/
│   ├── configs/          # Hyperparameter configs (versioned)
│   ├── scripts/          # Training entry points
│   └── experiments/      # MLflow/W&B experiment logs
├── serving/
│   ├── model/            # Serialized model artifacts
│   ├── api/              # Inference endpoint code
│   └── tests/            # Load tests, integration tests
├── monitoring/
│   ├── drift/            # Drift detection scripts
│   ├── alerts/           # Alert configs
│   └── dashboards/       # Monitoring dashboard configs
└── pipelines/
    ├── train.py          # End-to-end training pipeline
    ├── deploy.py         # Deployment automation
    └── retrain.py        # Retraining trigger logic

Reference Files

  • references/pipelines.md — Data validation, feature engineering, pipeline orchestration (Kubeflow, Airflow, Prefect)
  • references/training.md — Distributed training, HPO, transfer learning, ensemble strategies, advanced techniques
  • references/deployment.md — Serving frameworks (BentoML, Seldon, TorchServe), scaling, reliability, A/B testing
  • references/monitoring.md — Drift detection, alerting, retraining automation, incident response

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.