airflow-dag-patterns
Build production Apache Airflow DAGs with best practices for operators, sensors, testing, and deployment. Use when creating data pipelines, orchestrating workflows, or scheduling batch jobs.
82
71%
Does it follow best practices?
Impact
88%
1.07xAverage score across 6 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/data-engineering/skills/airflow-dag-patterns/SKILL.mdQuality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a strong skill description that concisely covers what the skill does (build Airflow DAGs with best practices across operators, sensors, testing, deployment) and when to use it (data pipelines, workflow orchestration, batch job scheduling). It uses third-person voice, includes highly relevant trigger terms, and is clearly distinguishable from other skills due to its Airflow-specific terminology.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: building DAGs, using operators, sensors, testing, and deployment. These are concrete, domain-specific capabilities rather than vague language. | 3 / 3 |
Completeness | Clearly answers both 'what' (build production Apache Airflow DAGs with best practices for operators, sensors, testing, and deployment) and 'when' (Use when creating data pipelines, orchestrating workflows, or scheduling batch jobs) with an explicit 'Use when...' clause. | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'Airflow', 'DAGs', 'data pipelines', 'orchestrating workflows', 'scheduling batch jobs', 'operators', 'sensors'. These cover the primary terms a user working with Airflow would naturally use. | 3 / 3 |
Distinctiveness Conflict Risk | Clearly scoped to Apache Airflow specifically, with domain-specific terms like 'DAGs', 'operators', 'sensors' that are distinctive to Airflow. Unlikely to conflict with general coding or other workflow tools. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides excellent, executable Airflow code examples covering a wide range of patterns, which is its primary strength. However, it is far too verbose—dumping six complete DAG implementations inline creates a massive document that wastes context window. The content would benefit enormously from being split into referenced files with only a quick-start example and navigation in the main SKILL.md.
Suggestions
Move patterns 2-6 into separate referenced files (e.g., patterns/dynamic_dags.md, patterns/sensors.md) and keep only the Quick Start and TaskFlow examples in SKILL.md with clear links to the others.
Remove the 'Core Concepts' section entirely—DAG design principles and task dependency syntax are basic Airflow knowledge Claude already has.
Add an explicit development/deployment workflow with validation steps: write DAG → run `airflow dags test` → run pytest → deploy, with feedback loops on failure.
Trim the Do's/Don'ts to only non-obvious, project-specific conventions rather than general Airflow best practices.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose at ~400+ lines. It explains basic concepts Claude already knows (DAG design principles table, task dependency syntax), includes multiple full DAG examples with boilerplate that could be condensed, and the 'Core Concepts' section is largely unnecessary padding. The Do's/Don'ts section restates common knowledge. | 1 / 3 |
Actionability | All code examples are fully executable, copy-paste ready Python with proper imports, realistic configurations, and complete DAG definitions. The testing patterns include concrete pytest fixtures and assertions. Every pattern is a working, runnable example. | 3 / 3 |
Workflow Clarity | The patterns are presented as standalone examples rather than a sequenced workflow. There are no explicit validation checkpoints for the development process (e.g., 'validate DAG loads before deploying', 'run tests before pushing'). The testing section exists but isn't integrated into a deployment workflow with feedback loops. | 2 / 3 |
Progressive Disclosure | The entire skill is a monolithic wall of text with six full pattern implementations inline. There are no references to external files despite the project structure suggesting files like operators.py, sensors.py, and callbacks.py exist. Content that should be split into separate reference files (dynamic DAGs, sensor patterns, testing) is all crammed into one document. | 1 / 3 |
Total | 7 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (520 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
- Repository
- wshobson/agents
- Commit
112197c
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.