airflow
This skill uses the `af` CLI to query, manage, and troubleshoot Apache Airflow instances.
Identity proven by GitHub's verified organisation badge (astronomer)
- Agents
- Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode
- License
- Apache-2.0 (permissive)
- Pin
- 486ee63pinned Oct 9, 2026
- Context cost
- about 3,600 tokenswhen the skill loads
- GitHub stars
- 451on astronomer/agents
- Scripts
- 1 script
What it does
“Queries, manages, and troubleshoots Apache Airflow using the `af` CLI. Use when working with anything related to Airflow - a DAG, a DAG run, a task log, an import or parse error, a broken DAG, or any Airflow operation. Covers listing and triggering DAGs, retrying runs, reading task logs, diagnosing failures, debugging import and parse errors, checking connections, variables and pools, exploring the REST API, and monitoring health (for example "trigger a pipeline", "retry a run", "list connections", "check Airflow health", "why did my DAG fail"). This is the entrypoint that routes to sibling skills for authoring, testing, deploying, and migrating Airflow 2 to 3. Not for warehouse/SQL analytics on Airflow metadata tables (use analyzing-data); for deep root-cause reports use debugging-dags or airflow-investigation.”
Generated summary from the skill's own text
This skill uses the `af` CLI to query, manage, and troubleshoot Apache Airflow instances. It covers listing and triggering DAGs, retrying runs, reading task logs, diagnosing failures, checking connections and variables, and accessing the REST API. The skill also manages multiple Airflow instances with persistent configuration.
When to use it
- List DAGs, trigger runs, or check task logs in Airflow
- Diagnose why a DAG or task failed to complete
- Query Airflow configuration like connections, variables, pools
- Access REST API endpoints not covered by high-level commands
When not to
- For writing or editing DAG code, use authoring-dags skill instead
- For SQL analytics on Airflow metadata, use analyzing-data skill
- For deep root-cause investigation, use debugging-dags skill
Install
These commands install from the publisher's repository and need no account.
skills CLI
npx skills add astronomer/agents --skill airflowInstalls from the repository's default branch, which may have changed since the commit we checked.
GitHub CLI 2.90 or later
gh skill install astronomer/agents airflow@486ee63d01f8126c52fbc92c36cd36ec31708dcdInstalls the commit we checked (486ee63).
Copy by hand
Download the folder at 486ee63 and put it in .claude/skills/airflow for Claude Code and in .agents/skills/airflow for Codex, Cursor, Gemini CLI, GitHub Copilot and OpenCode.
Claude Code plugin
/plugin install astronomer-data-agents@claude-plugins-officialThe publisher's plugin in Claude's official marketplace. It may hold more than this skill, and we have not pinned it.
Claude Code plugin
/plugin install data@claude-plugins-officialThe publisher's plugin in Claude's official marketplace. It may hold more than this skill, and we have not pinned it.
Claude Code plugin
/plugin install data-engineering@claude-plugins-officialThe publisher's plugin in Claude's official marketplace. It may hold more than this skill, and we have not pinned it.
Copy for your agent
A prompt for any coding agent. It installs this skill from GitHub at the pinned commit, copies the files as they are, and runs nothing unless you ask.
Prompt
Install the agent skill "airflow" by Astronomer. Source, pinned to commit 486ee63d01f8126c52fbc92c36cd36ec31708dcd: https://github.com/astronomer/agents/tree/486ee63d01f8126c52fbc92c36cd36ec31708dcd/skills/airflow 1. Download that folder at exactly this commit. Do not use the default branch. 2. Copy every file unchanged, keeping the folder structure, into .claude/skills/airflow/ for Claude Code and .agents/skills/airflow/ for Codex, Cursor, Gemini CLI, GitHub Copilot and OpenCode. Create the folders if they do not exist. 3. Do not edit the files, and do not run any script in the folder unless I ask you to. 4. When you are done, list the files you copied and where you put them. Listing and checks: https://www.agentnative.dev/skills/astronomer/airflow
SKILL.md at the pin
---
name: airflow
description: Queries, manages, and troubleshoots Apache Airflow using the `af` CLI. Use when working with anything related to Airflow - a DAG, a DAG run, a task log, an import or parse error, a broken DAG, or any Airflow operation. Covers listing and triggering DAGs, retrying runs, reading task logs, diagnosing failures, debugging import and parse errors, checking connections, variables and pools, exploring the REST API, and monitoring health (for example "trigger a pipeline", "retry a run", "list connections", "check Airflow health", "why did my DAG fail"). This is the entrypoint that routes to sibling skills for authoring, testing, deploying, and migrating Airflow 2 to 3. Not for warehouse/SQL analytics on Airflow metadata tables (use analyzing-data); for deep root-cause reports use debugging-dags or airflow-investigation.
---
# 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`).
Tokens in config can reference environment variables using `${VAR}` syntax:
```yaml
instances:
- name: prod
url: https://airflow.example.com
auth:
token: ${AIRFLOW_API_TOKEN}
```
Or use environment variables directly (no config file needed):
```bash
export AIRFLOW_API_URL=http://localhost:8080
export AIRFLOW_AUTH_TOKEN=your-token-here
# Or username/password:
export AIRFLOW_USERNAME=admin
export AIRFLOW_PASSWORD=admin
```
Or CLI flags: `af --airflow-url http://localhost:8080 --token "$TOKEN" <command>`
## Quick Reference
| Command | Description |
|---------|-------------|
| `af health` | System health check |
| `af dags list` | List all DAGs |
| `af dags get <dag_id>` | Get DAG details |
| `af dags explore <dag_id>` | Full DAG investigation |
| `af dags source <dag_id>` | Get DAG source code |
| `af dags pause <dag_id>` | Pause DAG scheduling |
| `af dags unpause <dag_id>` | Resume DAG scheduling |
| `af dags errors` | List import errors |
| `af dags warnings` | List DAG warnings |
| `af dags stats` | DAG run statistics |
| `af runs list` | List DAG runs |
| `af runs get <dag_id> <run_id>` | Get run details |
| `af runs trigger <dag_id>` | Trigger a DAG run |
| `af runs trigger-wait <dag_id>` | Trigger and wait for completion |
| `af runs delete <dag_id> <run_id>` | Permanently delete a DAG run |
| `af runs clear <dag_id> <run_id>` | Clear a run for re-execution |
| `af runs diagnose <dag_id> <run_id>` | Diagnose failed run |
| `af tasks list <dag_id>` | List tasks in DAG |
| `af tasks get <dag_id> <task_id>` | Get task definition |
| `af tasks instance <dag_id> <run_id> <task_id>` | Get task instance |
| `af tasks logs <dag_id> <run_id> <task_id>` | Get task logs |
| `af config version` | Airflow version |
| `af config show` | Full configuration |
| `af config connections` | List connections |
| `af config variables` | List variables |
| `af config variable <key>` | Get specific variable |
| `af config pools` | List pools |
| `af config pool <name>` | Get pool details |
| `af config plugins` | List plugins |
| `af config providers` | List providers |
| `af config assets` | List assets/datasets |
| `af api <endpoint>` | Direct REST API access |
| `af api ls` | List available API endpoints |
| `af api ls --filter X` | List endpoints matching pattern |
| `af registry providers` | List providers in the Airflow Registry |
| `af registry modules <provider>` | List operators/hooks/sensors/transfers in a provider |
| `af registry parameters <provider>` | Constructor signatures (name, type, default, required) for a provider's classes |
| `af registry connections <provider>` | Connection types a provider exposes |
## User Intent Patterns
### Getting Started
- "How do I run Airflow locally?" / "Set up Airflow" -> use the **managing-astro-local-env** skill (uses Astro CLI)
- "Create a new Airflow project" / "Initialize project" -> use the **setting-up-astro-project** skill (uses Astro CLI)
- "How do I install Airflow?" / "Get started with Airflow" -> use the **setting-up-astro-project** skill
### DAG Operations
- "What DAGs exist?" / "List all DAGs" -> `af dags list`
- "Tell me about DAG X" / "What is DAG Y?" -> `af dags explore <dag_id>`
- "What's the schedule for DAG X?" -> `af dags get <dag_id>`
- "Show me the code for DAG X" -> `af dags source <dag_id>`
- "Stop DAG X" / "Pause this workflow" -> `af dags pause <dag_id>`
- "Resume DAG X" -> `af dags unpause <dag_id>`
- "Are there any DAG errors?" -> `af dags errors`
- "Create a new DAG" / "Write a pipeline" -> use the **authoring-dags** skill
### Run Operations
- "What runs have executed?" -> `af runs list`
- "Run DAG X" / "Trigger the pipeline" -> `af runs trigger <dag_id>`
- "Run DAG X and wait" -> `af runs trigger-wait <dag_id>`
- "Why did this run fail?" -> `af runs diagnose <dag_id> <run_id>`
- "Delete this run" / "Remove stuck run" -> `af runs delete <dag_id> <run_id>`
- "Clear this run" / "Retry this run" / "Re-run this" -> `af runs clear <dag_id> <run_id>`
- "Test this DAG and fix if it fails" -> use the **testing-dags** skill
### Task Operations
- "What tasks are in DAG X?" -> `af tasks list <dag_id>`
- "Get task logs" / "Why did task fail?" -> `af tasks logs <dag_id> <run_id> <task_id>`
- "Full root cause analysis" / "Diagnose and fix" -> use the **debugging-dags** skill
### Data Operations
- "Is the data fresh?" / "When was this table last updated?" -> use the **checking-freshness** skill
- "Where does this data come from?" -> use the **tracing-upstream-lineage** skill
- "What depends on this table?" / "What breaks if I change this?" -> use the **tracing-downstream-lineage** skill
### Deployment Operations
- "Deploy my DAGs" / "Push to production" -> use the **deploying-airflow** skill
- "Set up CI/CD" / "Automate deploys" -> use the **deploying-airflow** skill
- "Deploy to Kubernetes" / "Set up Helm" -> use the **deploying-airflow** skill
- "astro deploy" / "DAG-only deploy" -> use the **deploying-airflow** skill
### System Operations
- "What version of Airflow?" -> `af config version`
- "What connections exist?" -> `af config connections`
- "Are pools full?" -> `af config pools`
- "Is Airflow healthy?" -> `af health`
### API Exploration
- "What API endpoints are available?" -> `af api ls`
- "Find variable endpoints" -> `af api ls --filter variable`
- "Access XCom values" / "Get XCom" -> `af api xcom-entries -F dag_id=X -F task_id=Y`
- "Get event logs" / "Audit trail" -> `af api event-logs -F dag_id=X`
- "Create connection via API" -> `af api connections -X POST --body '{...}'`
- "Create variable via API" -> `af api variables -X POST -F key=name -f value=val`
### Registry Discovery
- "What operators does provider X have?" -> `af registry modules <provider>`
- "What are the constructor params for operator Y?" -> `af registry parameters <provider>`
- "What providers exist?" / "Is there a provider for Z?" -> `af registry providers`
- "What connection types does provider X expose?" -> `af registry connections <provider>`
- "Writing a DAG with a specific operator" -> use registry to verify current signature before copying examples
## Common Workflows
### Validate DAGs Before Deploying
If you're using the Astro CLI, you can validate DAGs without a running Airflow instance:
```bash
# Parse DAGs to catch import errors and syntax issues
astro dev parse
# Run unit tests
astro dev pytest
```
Otherwise, validate against a running instance:
```bash
af dags errors # Check for parse/import errors
af dags warnings # Check for deprecation warnings
```
### Discover Operator Signatures Before Writing Code
The Airflow Registry at `airflow.apache.org/registry` is the authoritative source for provider classes and their current constructor signatures. Prefer it over memory or stale documentation when authoring DAGs — the registry reflects the live provider release.
```bash
# List all providers and pick the one you need
af registry providers | jq '.providers[] | {id, name, version}'
# List every operator / hook / sensor in a provider (e.g. standard, amazon, google)
af registry modules standard \
| jq '.modules[] | {name, type, import_path, docs_url}'
# Get the current constructor signature for a specific class
af registry parameters standard \
| jq '.classes["airflow.providers.standard.operators.hitl.ApprovalOperator"].parameters'
# Filter modules by substring (useful when you know the concept but not the class)
af registry modules standard \
| jq '.modules[] | select(.import_path | test("hitl"))'
```
Results are cached locally: 1 hour for the latest version, 30 days for pinned versions (which are immutable). Add `--version X.Y.Z` to any `modules` / `parameters` / `connections` call to target a specific release.
### Investigate a Failed Run
```bash
# 1. List recent runs to find failure
af runs list --dag-id my_dag
# 2. Diagnose the specific run
af runs diagnose my_dag manual__2024-01-15T10:00:00+00:00
# 3. Get logs for failed task (from diagnose output)
af tasks logs my_dag manual__2024-01-15T10:00:00+00:00 extract_data
# 4. After fixing, clear the run to retry all tasks
af runs clear my_dag manual__2024-01-15T10:00:00+00:00
```
### Morning Health Check
```bash
# 1. Overall system health
af health
# 2. Check for broken DAGs
af dags errors
# 3. Check pool utilization
af config pools
```
### Understand a DAG
```bash
# Get comprehensive overview (metadata + tasks + source)
af dags explore my_dag
```
### Check Why DAG Isn't Running
```bash
# Check if paused
af dags get my_dag
# Check for import errors
af dags errors
# Check recent runs
af runs list --dag-id my_dag
```
### Trigger and Monitor
```bash
# Option 1: Trigger and wait (blocking)
af runs trigger-wait my_dag --timeout 1800
# Option 2: Trigger and check later
af runs trigger my_dag
af runs get my_dag <run_id>
```
## Output Format
All commands output JSON (except `instance` commands which use human-readable tables):
```bash
af dags list
# {
# "total_dags": 5,
# "returned_count": 5,
# "dags": [...]
# }
```
Use `jq` for filtering:
```bash
# Find failed runs
af runs list | jq '.dag_runs[] | select(.state == "failed")'
# Get DAG IDs only
af dags list | jq '.dags[].dag_id'
# Find paused DAGs
af dags list | jq '[.dags[] | select(.is_paused == true)]'
```
## Task Logs Options
```bash
# Get logs for specific retry attempt
af tasks logs my_dag run_id task_id --try 2
# Get logs for mapped task index
af tasks logs my_dag run_id task_id --map-index 5
```
## Direct API Access with `af api`
Use `af api` for endpoints not covered by high-level commands (XCom, event-logs, backfills, etc).
```bash
# Discover available endpoints
af api ls
af api ls --filter variable
# Basic usage
af api dags
af api dags -F limit=10 -F only_active=true
af api variables -X POST -F key=my_var -f value="my value"
af api variables/old_var -X DELETE
```
**Field syntax**: `-F key=value` auto-converts types, `-f key=value` keeps as string.
**Full reference**: See [api-reference.md](api-reference.md) for all options, common endpoints (XCom, event-logs, backfills), and examples.
## Related Skills
| Skill | Use when... |
|-------|-------------|
| **authoring-dags** | Creating or editing DAG files with best practices |
| **testing-dags** | Iterative test -> debug -> fix -> retest cycles |
| **debugging-dags** | Deep root cause analysis and failure diagnosis |
| **checking-freshness** | Checking if data is up to date or stale |
| **tracing-upstream-lineage** | Finding where data comes from |
| **tracing-downstream-lineage** | Impact analysis -- what breaks if something changes |
| **deploying-airflow** | Deploying DAGs to production (Astro, Docker Compose, Kubernetes) |
| **migrating-airflow-2-to-3** | Upgrading DAGs from Airflow 2.x to 3.x |
| **managing-astro-local-env** | Starting, stopping, or troubleshooting local Airflow |
| **setting-up-astro-project** | Initializing a new Astro/Airflow project |
| **airflow-state-store** | Per-task checkpointing, watermarks, crash-safe operators (Airflow 3.3+) |
| **airflow-hitl** | Pausing a DAG for human approval or input (Airflow 3.1+) |
From astronomer/agents at 486ee63, shown as plain text under its license: Apache-2.0 (permissive). The license text is in LICENSE.
View SKILL.md on GitHub at 486ee63Files
- SKILL.md15 KB · b8ffa9f7857f
- api-reference.md2.8 KB · 2aa1ae5ab051
- hooks/
- warm-uvx-cache.sh408 B · be269d2ce0ab
3 files, 18 KB in total. Each file has a sha256 in the pin's manifest; the first 12 characters are shown.
Skill folder on GitHub at 486ee63More from Astronomer
airflow-adapter
This skill provides an adapter layer that automatically detects whether an agent is connected to Airflow 2.x or 3.x and routes API calls to the correct…
Claude Code · about 170 tokens · pinned 6 days ago
airflow-hitl
Implements human-in-the-loop workflows in Airflow 3.1+ using deferrable operators that pause DAGs and collect human decisions via the UI or REST API.
Claude Code, Codex, Cursor +4 · about 1.7K tokens · pinned 6 days ago
airflow-plugins
Builds Airflow 3.1+ plugins that embed FastAPI apps, custom UI pages, React components, middleware, macros, and operator links directly into the Airflow UI…
Claude Code, Codex, Cursor +4 · about 5.8K tokens · pinned 6 days ago
airflow-state-store
Helps agents work with Airflow 3.3's task and asset state stores for persisting coordination state across task retries, implementing crash-safe external job…
Claude Code, Codex, Cursor +4 · about 5.9K tokens · pinned 6 days ago
analyzing-data
Queries a data warehouse using SQL to answer business questions about metrics, trends, and aggregations.
Contains scripts
Claude Code, Codex, Cursor +3 · about 1.2K tokens · pinned 6 days ago
annotating-task-lineage
Add data lineage annotations to Airflow tasks using inlets and outlets, enabling tracking of data flow through datasets from various sources like Snowflake…
Claude Code, Codex, Cursor +4 · about 2.8K tokens · pinned 6 days ago
Related in Data and databases
authoring-dags
This skill guides agents through creating Apache Airflow DAGs following a structured workflow: discover existing patterns and environment, plan the DAG…
by AstronomerOfficial publisher
Claude Code · about 1.6K tokens · pinned 6 days ago
blueprint
Blueprint enables composing Apache Airflow DAGs from YAML templates using reusable Python task group classes with Pydantic validation.
by AstronomerOfficial publisher
Claude Code, Codex, Cursor +4 · about 8.3K tokens · pinned 6 days ago
checking-freshness
This skill queries databases to determine if data is current by finding timestamp columns and calculating how recently tables were updated.
by AstronomerOfficial publisher
Claude Code, Codex, Cursor +4 · about 750 tokens · pinned 6 days ago
creating-openlineage-extractors
This skill helps create custom OpenLineage extractors for Airflow operators to capture data lineage from unsupported or third-party operators.
by AstronomerOfficial publisher
Claude Code, Codex, Cursor +4 · about 3.2K tokens · pinned 6 days ago
debugging-dags
Diagnoses and fixes failed Airflow DAGs through systematic investigation of logs, error messages, and context.
by AstronomerOfficial publisher
Claude Code, Codex, Cursor +4 · about 1.7K tokens · pinned 6 days ago
migrating-dagster-to-airflow
This skill guides migrating Dagster projects to Apache Airflow 3 on Astro Runtime through a structured seven-phase process.
by AstronomerOfficial publisher
Contains scripts
Claude Code · about 3.6K tokens · pinned 6 days ago