Airflow
Run and troubleshoot Apache Airflow DAGs locally or in prod with the af CLI and Astro CLI without leaving your coding agent.
Overview
Airflow is an agent skill most often used in Operate (also Build integrations, Ship launch prep) that queries, manages, and troubleshoots Apache Airflow DAGs via the af CLI and Astro CLI.
Install
npx skills add https://github.com/astronomer/agents --skill airflowWhat is this skill?
- Query and manage DAGs, runs, task logs, connections, variables, and pools via the af CLI
- Diagnose broken DAGs, import/parse errors, and failed runs with guided troubleshooting flows
- Local dev with Astro CLI: `astro dev init/start/parse/pytest` and fast DAG-only deploys
- Routes to sub-skills for authoring DAGs, debugging, deploying, and Airflow 2→3 migration
- Explicit boundary: not for warehouse/SQL analytics on Airflow metadata—use analyzing-data instead
- Astro local web UI defaults to http://localhost:8080
- Supports full image deploy and fast DAG-only deploy via `astro deploy --dags`
Adoption & trust: 955 installs on skills.sh; 384 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You depend on Airflow pipelines but waste time switching tools to trigger runs, read logs, or chase import errors and connection issues.
Who is it for?
Indie builders or tiny data teams operating Astronomer/Astro or self-hosted Airflow who want agent-driven runbooks for DAG ops and local reproduction.
Skip if: Teams that only need SQL or BI on Airflow metadata tables, or builders with no Airflow deployment who should pick a simpler scheduler first.
When should I use this skill?
User mentions Airflow, DAG, DAG run, task log, import/parse error, broken DAG, triggering a pipeline, Airflow health, connections, variables, pools, or retrying a run.
What do I get? / Deliverables
You get repeatable af and Astro CLI steps to inspect DAG health, fix failures, and deploy DAG changes, with clear routing to authoring and migration skills when the fix is not operational.
- Executed af/Astro command sequences for inspect or fix
- Diagnosis notes for DAG import or run failures
- Local or remote deploy steps for DAG changes
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Operate because the skill centers on live DAG runs, health checks, retries, logs, and production deploy commands—not greenfield app UI. Infra fits pipeline orchestration, connections, pools, and deployment (`astro deploy`) as production workflow infrastructure.
Where it fits
Parse DAGs with `astro dev parse` after adding a new operator before merging.
Run pytest on DAGs and do a DAG-only `astro deploy --dags` ahead of a scheduled launch.
Pull task logs and retry a failed run when a nightly sync alerts.
List connections and pools to verify secrets and concurrency before scaling workers.
How it compares
Operational Airflow CLI skill package—not a warehouse analytics skill and not a generic cron substitute.
Common Questions / FAQ
Who is airflow for?
Solo builders and small teams who ship batch or ETL pipelines on Apache Airflow and want their coding agent to run inspections, triggers, and triage with af and Astro CLI.
When should I use airflow?
Use it during Build when wiring integrations and testing DAG parse locally; during Ship when validating launch-ready schedules; and during Operate when retrying failed runs, reading task logs, checking connections, or deploying DAG-only updates to production.
Is airflow safe to install?
Treat it like any skill that can drive shell and deploy commands: review the Security Audits panel on this Prism page and restrict credentials before letting an agent trigger production runs.
SKILL.md
READMESKILL.md - Airflow
# Airflow Operations Use `af` commands to query, manage, and troubleshoot Airflow workflows. ## Astro CLI The [Astro CLI](https://www.astronomer.io/docs/astro/cli/overview) is the recommended way to run Airflow locally and deploy to production. It provides a containerized Airflow environment that works out of the box: ```bash # Initialize a new project astro dev init # Start local Airflow (webserver at http://localhost:8080) astro dev start # Parse DAGs to catch errors quickly (no need to start Airflow) astro dev parse # Run pytest against your DAGs astro dev pytest # Deploy to production astro deploy # Full deploy (image + DAGs) astro deploy --dags # DAG-only deploy (fast, no image build) ``` For more details: - **New project?** See the **setting-up-astro-project** skill - **Local environment?** See the **managing-astro-local-env** skill - **Deploying?** See the **deploying-airflow** skill --- ## Running the CLI These commands assume `af` is on PATH. Run via `astro otto` to get it automatically, or install standalone with `uv tool install astro-airflow-mcp`. ## Instance Configuration Manage multiple Airflow instances with persistent configuration: ```bash # Add a new instance af instance add prod --url https://airflow.example.com --token "$API_TOKEN" af instance add staging --url https://staging.example.com --username admin --password admin # List and switch instances af instance list # Shows all instances in a table af instance use prod # Switch to prod instance af instance current # Show current instance af instance delete old-instance # Auto-discover instances (use --dry-run to preview first) af instance discover --dry-run # Preview all discoverable instances af instance discover # Discover from all backends (astro, local) af instance discover astro # Discover Astro deployments only af instance discover astro --all-workspaces # Include all accessible workspaces af instance discover local # Scan common local Airflow ports af instance discover local --scan # Deep scan all ports 1024-65535 # IMPORTANT: Always run with --dry-run first and ask for user consent before # running discover without it. The non-dry-run mode creates API tokens in # Astro Cloud, which is a sensitive action that requires explicit approval. # Show where an instance came from (file path + scope) af instance show prod # Override instance for a single command via env vars AIRFLOW_API_URL=https://staging.example.com AIRFLOW_AUTH_TOKEN=$STG af dags list # Or switch persistently af instance use staging ``` Config layout (mirrors `git config` system/global/local): | Scope | File | Committed? | |---|---|---| | Global | `~/.astro/config.yaml` | n/a (per-user) | | Project shared | `<root>/.astro/config.yaml` | yes | | Project local | `<root>/.astro/config.local.yaml` | no (gitignored) | `<root>` is found by walking up from cwd looking for `.astro/`. Default write routing inside a project: `add`/`discover` → project-shared, `use` → project-local. Override with `--global` / `--project` / `--local`. Set `AF_CONFIG=<path>` to bypass layering and use a single file. Migrate from the legacy `~/.af/config.yaml` with `af migrate` (idempotent; renames the old file to `.bak`