Stats
Actions
Available In
Tags
Plugin
ml-engineering
ML-engineering (MLOps) team — 4 agents (ml-platform-architect, training-pipeline-engineer, model-serving-engineer, ml-monitoring-engineer) for the PRODUCTION lifecycle of ML models: the platform/architecture (build-vs-buy, the stack, the train->register->serve->monitor loop), reproducible training pipelines + experiment tracking + a model registry, feature stores and train/serve consistency (avoiding training-serving skew and leakage), model serving (online vs batch, shadow/canary), monitoring (data + concept drift, decay, retraining triggers), and computer-vision MLOps (task->architecture + edge-vs-cloud inference). 6 skills, a decision-tree knowledge bank (serving-pattern + retraining + computer-vision trees + a dated 2026 map), 25 best-practices, 4 templates, 4 commands, 1 advisory hook. Seams: significance -> applied-statistics, data pipelines -> data-platform/data-streaming, LLM/agent apps -> claude-app-engineering, deploy -> devops-cicd/cloud-native-kubernetes. Requires ravenclaude-core@>=0.7.0.
What's Inside
Slash Commands4
Steps
/build-training-pipeline
Build a reproducible training pipeline with experiment tracking, a registry, feature consistency, and leakage-free validation.
Steps
/deploy-model
Deploy a model: choose online vs batch, serve a registered version, optimize latency, and roll out shadow->canary->full.
Steps
/design-mlops-platform
Design the train->register->serve->monitor MLOps lifecycle matched to team maturity, with a build-vs-buy stack choice.
Steps
/monitor-model
Set up drift + decay monitoring with thresholds, alerts, and a retraining trigger that closes the loop to training.
Agents4
ml-monitoring-engineer
/ml-monitoring-engineer
Use for production model monitoring: data drift, prediction/concept drift, performance decay (when labels arrive), defining the retraining trigger (schedule/threshold/drop), distinguishing data vs concept drift, alerting on model health, and closing the loop to retraining.
ml-platform-architect
/ml-platform-architect
Use for MLOps architecture: designing the full train->register->serve->monitor lifecycle, build-vs-buy of the ML stack matched to team maturity, structural reproducibility (versioned data/code/config/env + model registry), and governance/lineage.
model-serving-engineer
/model-serving-engineer
Use for model serving: choosing online vs batch inference, serving from the registry as a versioned artifact, latency/cost optimization (batching, quantization/distillation, hardware) to a budget, and safe rollout (shadow -> canary -> full) with a promotion metric and rollback.
training-pipeline-engineer
/training-pipeline-engineer
Use for reproducible training: pipelines (prep->train->evaluate->register), experiment tracking, a model registry, feature stores / shared transforms for train-serve consistency, leakage-free time-aware validation, and budgeted hyperparameter tuning.
Skills6
computer-vision-pipeline
/computer-vision-pipeline
Run the computer-vision MLOps lane end to end: data/annotation -> CV task -> architecture choice -> training (transfer-learn first) -> eval by task (mAP/IoU/CER/OKS) -> serving/edge placement. CV-specific leakage (scene-aware split, augment-after-split). Seams back to training/serving/monitoring agents.
feature-store-consistency
/feature-store-consistency
Prevent training-serving skew: compute features once via a feature store or shared transformation so training and serving use identical logic, with point-in-time correctness for temporal features and no leakage of future data.
ml-experiment-tracking
/ml-experiment-tracking
Playbook for setting up and operating an experiment tracking system (MLflow or Weights and Biases) — what to log, run comparison workflow, promotion to the model registry, and avoiding the common leakage and cherry-picking pitfalls.
model-monitoring
/model-monitoring
Keep production models honest: monitor input/data drift, prediction/concept drift, and performance decay (when labels arrive); define the retraining trigger up front (schedule/threshold/drop); alert on model health; and close the loop to retraining.
model-serving
/model-serving
Serve models reliably: choose online vs batch by the use case, deploy a versioned model from the registry, optimize latency to a budget (batching/quantization/distillation/hardware), and roll out safely with shadow -> canary -> full.
LSP Servers1
Stats
Version0.4.5
LanguageHTML
Stars4
Forks1
MaintenanceExcellent
LicenseMIT
Last Commit
Added
Available In
Safety Signals
Caution
Modifies files
Hook triggers on file write and edit operations
Uses power tools
Uses Bash, Write, or Edit tools
'%20stop-opacity%3D'0.16'%2F%3E%3Cstop%20offset%3D'1'%20stop-color%3D'rgb(200%2C90%2C60)'%20stop-opacity%3D'0.03'%2F%3E%3C%2FlinearGradient%3E%3C%2Fdefs%3E%3Crect%20width%3D'320'%20height%3D'200'%20fill%3D'url(%23g)'%2F%3E%3Ccircle%20cx%3D'250'%20cy%3D'56'%20r%3D'92'%20fill%3D'rgb(200%2C90%2C60)'%20fill-opacity%3D'0.06'%2F%3E%3Ccircle%20cx%3D'64'%20cy%3D'172'%20r%3D'58'%20fill%3D'rgb(200%2C90%2C60)'%20fill-opacity%3D'0.05'%2F%3E%3C%2Fsvg%3E)
