authoring-dags
Skill459 starsChanged 36 days agoApache-2.0View on GitHub
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.
1 other project uses a version of this, 1 of them edited.
Adopted by
Most recently taken up by
- miptah21/skillsedited, first seen May 26, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 1
- miptah21/skills★ 294% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository35 other files it gives its agents.
- AGENTS.mdAGENTS.md
- astro-airflow-mcp/AGENTS.mdAGENTS.md
- airflow-hitlSkill
- airflow-pluginsSkill
- airflowSkill
- airflow-state-storeSkill
- analyzing-dataSkill
- annotating-task-lineageSkill
- authoring-go-sdk-tasksSkill
- authoring-java-sdk-tasksSkill
- authoring-language-sdk-tasksSkill
- blueprintSkill
- checking-freshnessSkill
- configuring-airflow-language-sdksSkill
- cosmos-dbt-coreSkill
- cosmos-dbt-fusionSkill
- creating-openlineage-extractorsSkill
- dag-factorySkill
- debugging-dagsSkill
- delegating-to-ottoSkill
- deploying-airflowSkill
- deploying-go-sdk-bundlesSkill
- deploying-java-sdk-bundlesSkill
- managing-astro-deploymentsSkill
- managing-astro-local-envSkill
- migrating-airflow-2-to-3Skill
- migrating-ai-sdk-to-common-aiSkill
- migrating-dagster-to-airflowSkill
- profiling-tablesSkill
- setting-up-astro-projectSkill
- testing-dagsSkill
- tracing-downstream-lineageSkill
- tracing-upstream-lineageSkill
- troubleshooting-astro-deploymentsSkill
- warehouse-initSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
15 rules. About 0 are common, 10 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈10
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 63
Before writing code, understand the context.
- Distinctive: line 67
Use file tools to find existing patterns:
- Very specific: line 70
Check requirements.txt for available packages
- Very specific: line 74
Use af CLI commands to understand what's available:
- Distinctive: line 108
Write the DAG following best practices (see below).
- Distinctive: line 110
Create DAG file in appropriate location
- Very specific: line 111
Update requirements.txt if needed
- Distinctive: line 122
After saving, check for parse errors (Airflow will have already parsed the file):
- Distinctive: line 128
If your file appears -> fix and retry
- Distinctive: line 129
If no errors -> continue
- Distinctive: line 139
Check: DAG exists, schedule correct, tags set, paused status.
- Distinctive: line 147
Look for deprecation warnings or configuration issues.
- Distinctive: line 159
If you're running on Astro, you can also validate locally before deploying:
- Very specific: line 161
Parse check: Run astro dev parse to catch import errors and DAG-level issues without starting a full Airflow environment
- Very specific: line 192
Check for import errors: af dags errors
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
DAG Authoring 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.
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.
Workflow Overview
+-----------------------------------------+
| 1. DISCOVER |
| Understand codebase & environment |
+-----------------------------------------+
|
+-----------------------------------------+
| 2. PLAN |
| Propose structure, get approval |
+-----------------------------------------+
|
+-----------------------------------------+
| 3. IMPLEMENT |
| Write DAG following patterns |
+-----------------------------------------+
|
+-----------------------------------------+
| 4. VALIDATE |
| Check import errors, warnings |
+-----------------------------------------+
|
+-----------------------------------------+
| 5. TEST (with user consent) |
| Trigger, monitor, check logs |
+-----------------------------------------+
|
+-----------------------------------------+
| 6. ITERATE |
| Fix issues, re-validate |
+-----------------------------------------+Phase 1: Discover
Before writing code, understand the context.
Explore the Codebase
Use file tools to find existing patterns:
Globfor**/dags/**/*.pyto find existing DAGsReadsimilar DAGs to understand conventions- Check
requirements.txtfor available packages
Query the Airflow Environment
Use 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:
- "Is there a Snowflake connection?" ->
af config connections - "What Airflow version?" ->
af config version - "Are S3 operators available?" ->
af config providers
Phase 2: Plan
Based on discovery, propose:
- DAG structure - Tasks, dependencies, schedule
- Operators to use - Based on available providers
- Connections needed - Existing or to be created
- Variables needed - Existing or to be created
- Packages needed - Additions to requirements.txt
Get user approval before implementing.
Phase 3: Implement
Write the DAG following best practices (see below). Key steps:
- Create DAG file in appropriate location
- Update
requirements.txtif needed - Save the file
Phase 4: Validate
Use af CLI as a feedback loop to validate your DAG.
Step 1: Check Import Errors
After saving, check for parse errors (Airflow will have already parsed the file):
af dags errors- If your file appears -> fix and retry
- If no errors -> continue
Common causes: missing imports, syntax errors, missing packages.
Step 2: Verify DAG Exists
af dags get <dag_id>Check: DAG exists, schedule correct, tags set, paused status.
Step 3: Check Warnings
af dags warningsLook for deprecation warnings or configuration issues.
Step 4: Explore DAG Structure
af dags explore <dag_id>Returns in one call: metadata, tasks, dependencies, source code.
On Astro
If you're running on Astro, you can also validate locally before deploying:
- Parse check: Run
astro dev parseto catch import errors and DAG-level issues without starting a full Airflow environment - DAG-only deploy: Once validated, use
astro deploy --dagsfor fast DAG-only deploys that skip the Docker image build — ideal for iterating on DAG code
Phase 5: Test
See the testing-dags skill for comprehensive testing guidance.
Once validation passes, test the DAG using the workflow in the testing-dags skill:
- Get user consent -- Always ask before triggering
- Trigger and wait --
af runs trigger-wait <dag_id> --timeout 300 - Analyze results -- Check success/failure status
- Debug if needed --
af runs diagnose <dag_id> <run_id>andaf tasks logs <dag_id> <run_id> <task_id>
Quick Test (Minimal)
# Ask user first, then:
af runs trigger-wait <dag_id> --timeout 300For the full test -> debug -> fix -> retest loop, see testing-dags.
Phase 6: Iterate
If issues found:
- Fix the code
- Check for import errors:
af dags errors - Re-validate (Phase 4)
- Re-test using the testing-dags skill workflow (Phase 5)
CLI Quick Reference
| 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.
Best Practices & Anti-Patterns
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.
Related Skills
- testing-dags: For testing DAGs, debugging failures, and the test -> fix -> retest loop
- debugging-dags: For troubleshooting failed DAGs
- deploying-airflow: For deploying DAGs to production (Astro or open-source)
- migrating-airflow-2-to-3: For migrating DAGs to Airflow 3
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

