Generate Argo Workflows with YAML
An Argo Workflows skill for writing Kubernetes YAML pipelines with DAG templates, artifacts, retries, secrets, and Prometheus metrics.
Why it matters
Automate the creation of complex, container-native workflows for Kubernetes using Argo. This asset generates efficient and scalable YAML definitions for tasks, dependencies, and artifact management.
Outcomes
What it gets done
Generate container and script templates for Argo Workflows.
Define DAGs for complex task dependencies and parallel execution.
Implement artifact management for passing data between steps.
Incorporate security best practices for secrets and resource management.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/vb-argo-workflow-generator | bash Overview
Argo Workflow Generator Agent
A skill for writing Argo Workflows YAML on Kubernetes, covering container, script, and DAG template types, artifact passing via S3 or MinIO, and conditional or parallel execution with withItems. It includes production patterns for secrets via secretKeyRef, retry strategies with backoff, resource limits, and Prometheus metrics. Use it when designing Kubernetes-native CI/CD or data pipelines on Argo Workflows that need explicit dependency graphs, parallel execution, or artifact passing - not for general Kubernetes cluster configuration outside Argo's workflow model.
What it does
This skill provides expert Argo Workflows generation - the container-native workflow engine for orchestrating parallel tasks in Kubernetes - covering YAML specifications, template types, dependencies, artifacts, and resource management. It structures every workflow around the core apiVersion/kind/metadata/spec pattern with an entrypoint and parameters, then covers three template types: container templates for single containerized tasks, script templates for multi-step Python logic embedded directly in the workflow, and DAG templates for expressing task dependencies and parallel execution explicitly (test then build, then security-scan and deploy in parallel where dependencies allow). It covers artifact management for passing files between steps via S3-compatible storage (including MinIO endpoint configuration), conditional execution using step-output-based when clauses, loops and parallelism via withItems and a parallelism cap, and resource management with CPU/memory requests and limits, node selectors, and tolerations.
When to use - and when NOT to
Use this skill when designing or reviewing Argo Workflow YAML for Kubernetes-native CI/CD or data pipelines that need explicit dependency graphs, parallel task execution, or artifact passing between steps - the DAG template pattern (test, then build, then security-scan and deploy in parallel) is built for exactly this kind of multi-stage pipeline. It also covers production concerns directly: Kubernetes secrets via secretKeyRef instead of hardcoded credentials, least-privilege RBAC through serviceAccountName, retry strategies with exponential backoff, exit handlers for cleanup, and Prometheus metrics for workflow duration. It is not a general Kubernetes deployment guide - it's scoped to Argo's own workflow, template, and artifact model rather than broader cluster configuration.
Inputs and outputs
- name: ci-pipeline
dag:
tasks:
- name: test
template: run-tests
- name: build
template: build-image
dependencies: [test]
- name: security-scan
template: security-scan
dependencies: [build]
- name: deploy
template: deploy-app
dependencies: [build, security-scan]
Given a pipeline requirement, it produces complete Argo Workflow YAML: the top-level spec with entrypoint and arguments, container or script templates for the actual work, a DAG or steps block encoding dependencies like the one above, artifact input/output blocks wired to S3 or MinIO storage, retryStrategy blocks with backoff duration/factor/maxDuration, resource requests/limits and node placement rules, and metadata labels/annotations plus Prometheus metrics blocks for observability.
Who it's for
Platform and DevOps engineers building Kubernetes-native CI/CD or data pipelines on Argo Workflows who need production-ready YAML covering not just the happy path but secrets handling, retries, resource limits, and monitoring from the start. It suits teams that want reusable workflow templates across the organization and that validate every workflow with argo lint before submission, per the skill's own closing guidance.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.