npx skills add ...
npx skills add astronomer/agents --skill authoring-dags
npx skills add astronomer/agents --skill authoring-dags
Workflow and best practices for writing Apache Airflow DAGs. Use when creating a new DAG, write pipeline code, handling questions about DAG patterns and conventions or extending an existing DAG with a follow-up/downstream task. ANY request shaped like 'add a DAG named X', 'write a pipeline', 'add a task that runs after Y', or 'extend the DAG'. For testing and debugging DAGs, see the testing-dags skill.
This skill guides you through creating and validating Airflow DAGs using best practices and af CLI commands.
For testing and debugging DAGs, see the testing-dags skill which covers the full test -> debug -> fix -> retest workflow.
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.
Before writing code, understand the context.
Use file tools to find existing patterns:
Glob for **/dags/**/*.py to find existing DAGsRead similar DAGs to understand conventionsrequirements.txt for available packagesUse af CLI commands to understand what's available:
| Command | Purpose |
|---|---|
af config connections | What external systems are configured |
af config variables | What configuration values exist |
af config providers | What operator packages are installed |
af config version | Version constraints and features |
af dags list | Existing DAGs and naming conventions |
af config pools | Resource pools for concurrency |
Example discovery questions:
af config connectionsaf config versionaf config providersBased on discovery, propose:
Get user approval before implementing.
Write the DAG following best practices (see below). Key steps:
requirements.txt if neededUse af CLI as a feedback loop to validate your DAG.
After saving, check for parse errors (Airflow will have already parsed the file):
Common causes: missing imports, syntax errors, missing packages.
Check: DAG exists, schedule correct, tags set, paused status.
Look for deprecation warnings or configuration issues.
Returns in one call: metadata, tasks, dependencies, source code.
If you're running on Astro, you can also validate locally before deploying:
astro dev parse to catch import errors and DAG-level issues without starting a full Airflow environmentastro deploy --dags for fast DAG-only deploys that skip the Docker image build — ideal for iterating on DAG codeSee the testing-dags skill for comprehensive testing guidance.
Once validation passes, test the DAG using the workflow in the testing-dags skill:
af runs trigger-wait <dag_id> --timeout 300af runs diagnose <dag_id> <run_id> and af tasks logs <dag_id> <run_id> <task_id>For the full test -> debug -> fix -> retest loop, see testing-dags.
If issues found:
af dags errors| Phase | Command | Purpose |
|---|---|---|
| Discover | af config connections | Available connections |
| Discover | af config variables | Configuration values |
| Discover | af config providers | Installed operators |
| Discover | af config version | Version info |
| Validate | af dags errors | Parse errors (check first!) |
| Validate | af dags get <dag_id> | Verify DAG config |
| Validate | af dags warnings | Configuration warnings |
| Validate | af dags explore <dag_id> | Full DAG inspection |
Testing commands -- See the testing-dags skill for
af runs trigger-wait,af runs diagnose,af tasks logs, etc.
For code patterns and anti-patterns, see reference/best-practices.md.
Read this reference when writing new DAGs or reviewing existing ones. It covers what patterns are correct (including Airflow 3-specific behavior) and what to avoid.
af dags errorsaf dags get <dag_id>af dags warningsaf dags explore <dag_id># Ask user first, then:
af runs trigger-wait <dag_id> --timeout 300