Implements ZenML quick wins to enhance MLOps workflows. Investigates codebase and stack configuration, recommends high-priority improvements, and implements metadata logging, experiment tracking, alerts, scheduling, secrets management, tags, git hooks, HTML reports, and Model Control Plane setup. Use when: user wants to improve their ZenML setup, asks about MLOps best practices, mentions "quick wins", wants to enhance pipelines, or needs help with ZenML features like experiment tracking, alerting, scheduling, or model governance.
Implements ZenML quick wins to enhance MLOps workflows. Investigates codebase and stack configuration, recommends high-priority improvements, and implements metadata logging, experiment tracking, alerts, scheduling, secrets management, tags, git hooks, HTML reports, and Model Control Plane setup. Use when: user wants to improve their ZenML setup, asks about MLOps best practices, mentions "quick wins", wants to enhance pipelines, or needs help with ZenML features like experiment tracking, alerting, scheduling, or model governance.
ZenML Quick Wins Implementation
Guides users through discovering and implementing high-impact ZenML features that take ~5 minutes each. Investigates current setup, recommends priorities, and implements chosen improvements.
Workflow Overview
┌─────────────────────┐
│ 1. INVESTIGATE │ Understand current stack + codebase
└──────────┬──────────┘
▼
┌─────────────────────┐
│ 2. CONFIRM │ ⏸️ Check understanding with user
└──────────┬──────────┘
▼
┌─────────────────────┐
│ 3. GATHER CONTEXT │ ⏸️ Get additional context from user
└──────────┬──────────┘
▼
┌─────────────────────┐
│ 4. RECOMMEND │ Prioritize quick wins based on findings
└──────────┬──────────┘
▼
┌─────────────────────┐
│ 5. PREPARE │ ⏸️ Verify branch setup before changes
└──────────┬──────────┘
▼
┌─────────────────────┐
│ 6. IMPLEMENT │ Apply selected quick wins
└──────────┬──────────┘
▼
┌─────────────────────┐
│ 7. VERIFY │ Confirm implementation works
└─────────────────────┘
⏸️ = User checkpoint (uses AskUserQuestion tool)
Phase 1: Investigation
Use subagents to gather information efficiently. This keeps verbose output out of the main conversation while enabling parallel investigation.
Recommended: Parallel Subagent Investigation
Spawn both subagents in parallel using a single Task tool call with multiple invocations:
Use the Task tool to launch BOTH agents simultaneously:
1. zenml-quick-wins:zenml-stack-investigator agent:
- Prompt: "Investigate the ZenML stack configuration for this project.
Run all the ZenML CLI commands to understand stacks, components,
and recent pipeline activity. Return a structured summary."
2. zenml-quick-wins:zenml-codebase-analyzer agent:
- Prompt: "Analyze the Python codebase for ZenML patterns and quick win
opportunities. Search for pipeline definitions, current feature usage,
and areas for improvement. Return a structured summary."
Both agents run concurrently and return structured summaries. Synthesize their findings before proceeding to Phase 2.
If subagents are unavailable, run these commands directly.
First, activate the Python environment:
# Check for uv projectif [ -f "pyproject.toml" ] && command -v uv &> /dev/null; then# Use "uv run zenml ..." for all commands belowecho"Using uv - prefix commands with 'uv run'"fi# Or activate venv/condasource .venv/bin/activate 2>/dev/null || source venv/bin/activate 2>/dev/null || echo"No venv found"# Verify zenml is available
zenml version
Then run the investigation commands:
# Core stack info
zenml status
zenml stack list --output=json
zenml stack describe
# Component details
zenml experiment-tracker list 2>/dev/null || echo"No experiment trackers"
zenml alerter list 2>/dev/null || echo"No alerters configured"
zenml secret list 2>/dev/null || echo"No secrets or no access"
zenml code-repository list 2>/dev/null || echo"No code repos connected"
zenml model list 2>/dev/null || echo"No models registered"# Recent runs (check for metadata usage)
zenml pipeline runs list --size=10 --output=json 2>/dev/null
MCP Server Check
If ZenML MCP server is available, use it for deeper exploration:
# Check if zenml MCP tools are available# If yes, use them to query pipelines, runs, artifacts
Phase 2: Confirm Understanding ⏸️
IMPORTANT: Stop and check in with the user before proceeding.
After investigation, summarize what you've learned and use the AskUserQuestion tool to confirm your understanding. This prevents wasted effort from misunderstandings.
What to Summarize
Present your findings clearly:
Stack Configuration
Which stacks exist (local, staging, production, etc.)
What the active stack contains (orchestrator type, artifact store, etc.)
Any connected components (experiment trackers, alerters, secrets stores)
Pipeline Execution Patterns
How pipelines appear to be run (manual vs scheduled vs triggered)
If schedules exist, note them explicitly
Any orchestrator-specific patterns (Airflow DAGs, Kubeflow pipelines, etc.)
Current Feature Usage
Which ZenML features are already in use (metadata, tags, models, etc.)
What's missing that could be quick wins
Confirmation Questions
Use AskUserQuestion with questions like:
Stack Usage:
"I found these stacks: [list]. Which is your primary development stack, and which is production?"
"Is default stack used for local development, or do you use a different one?"
Pipeline Execution:
"I see [N] recent runs. Are these primarily manual runs, or is there a schedule I might have missed?"
"The pipeline appears to run on [orchestrator]. Is this your main execution environment?"
Feature Gaps:
"I noticed [feature] isn't being used yet. Is that intentional, or an area you'd like to improve?"
Example Confirmation Message
## 📋 Here's what I understand about your ZenML setup:**Stacks:**-`default` - Local stack (seems to be for development)
-`aws-production` - AWS stack with SageMaker orchestrator
**Active Stack:**`default` (LocalOrchestrator, local artifact store)
**Recent Activity:**- 47 pipeline runs in the last month
- All appear to be manual runs (no schedules detected)
- Using `training_pipeline` and `inference_pipeline`**Current Features:**- ✅ Basic pipeline structure
- ❌ No metadata logging detected
- ❌ No tags on pipelines
- ❌ No Model Control Plane usage
**Questions for you:**1. Is `default` your local dev stack and `aws-production` for production?
2. Are these pipelines meant to run on a schedule, or is manual execution intentional?
3. Any other stacks or environments I should know about?
Wait for user confirmation before proceeding to Phase 3.
Phase 3: Gather Context ⏸️
IMPORTANT: Gather tacit knowledge that isn't captured in code.
Before making recommendations, ask about context that affects implementation choices. Use AskUserQuestion to learn about:
Infrastructure Context
"Are there any infrastructure constraints or gotchas I should know about?"
"Any cloud resource limits, network restrictions, or compliance requirements?"
"Is there a shared artifact store, or does each environment have its own?"
Development Environment
"How do you typically develop and test pipelines locally before deploying?"
"Do you use a specific IDE, and is there any tooling I should be aware of?"
"Any CI/CD pipelines that interact with ZenML?"
Team Dynamics
"Is this a solo project or does a team work on these pipelines?"
"If team: any conventions or patterns the team follows that I should maintain?"
"Any upcoming changes or migrations planned that might affect recommendations?"
Operational Patterns
"How do you currently monitor pipeline health and failures?"
"When something breaks, how do you typically find out?"
"Any preferences for where alerts should go (Slack, email, etc.)?"
Example Context Gathering
## 🔍 Before I make recommendations, some questions:**Infrastructure:**- Any constraints I should know about (resource limits, compliance, network)?
- Anything that's worked poorly in the past with this setup?
**Development:**- How does local development/testing work for your team?
- Any CI/CD integration with ZenML?
**Team:**- Solo project or team? (affects things like git hooks, naming conventions)
- Any established patterns or conventions I should follow?
**Operations:**- How do you currently learn about pipeline failures?
- Preferences for alerting (Slack, Discord, email)?
Incorporate this context into your recommendations in Phase 4.
Use AskUserQuestion to ask which quick wins they want to implement based on your findings and their priorities. Present the most relevant options first based on the context gathered in previous phases.
Phase 5: Prepare ⏸️
IMPORTANT: Verify git and branch setup before making any changes.
Before implementing any quick wins, ensure the codebase is ready for changes.
Git Status Check
# Check current branch and status
git status
git branch --show-current
# Check for uncommitted changes
git diff --stat
Branch Confirmation
Use AskUserQuestion to confirm branch setup:
## 🌿 Before I make changes, let's confirm the branch setup:**Current state:**- Branch: `main` (or whatever branch)
- Status: [clean / X uncommitted changes]
**Questions:**1. Should I create a feature branch for these changes? (Recommended: `feature/zenml-quick-wins`)
2. If yes, is `main` the correct base branch, or should I branch from somewhere else (e.g., `develop`)?
3. Any branch naming conventions I should follow?
Create Feature Branch (if confirmed)
# Create and checkout feature branch
git checkout -b feature/zenml-quick-wins
# Or with their naming convention
git checkout -b <their-preferred-name>
Why This Matters
Prevents accidental commits to protected branches
Allows easy rollback if something goes wrong
Follows standard development workflow practices
Makes it easier to review changes before merging
Implementation Approach ⏸️
Before starting implementation, use AskUserQuestion to ask about the preferred approach:
## 📝 How would you like to proceed with implementation?**Option A: Write a plan first (Recommended)**
I can write a detailed implementation plan as a `.md` file that you can:
- Review and share with your team before changes are made
- Use as documentation of what will be implemented
- Reference during code review
After the plan is approved, I'd recommend compacting this session to start fresh with clean context for implementation.
**Option B: Proceed directly to implementation**
I'll start implementing the selected quick wins right away.
**Questions:**1. Would you like a written plan first, or shall we proceed directly?
2. If writing a plan: where should I save it? (e.g., `docs/zenml-quick-wins-plan.md`)
Why offer this choice:
Teams often want to review proposed changes before implementation
A written plan serves as documentation and can be referenced in PRs
Compacting the session before implementation clears investigation context, keeping the model focused on the task at hand
Some users prefer to move fast; others prefer deliberate planning
