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 specific capabilities (DAGs, operators, sensors, testing, deployment), uses natural trigger terms users would employ, and includes an explicit 'Use when' clause. It uses proper third-person voice and is clearly distinguishable from other skills due to the specific Apache Airflow domain focus.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: building DAGs, working with operators, sensors, testing, and deployment. These are concrete, domain-specific capabilities rather than vague abstractions. | 3 / 3 |
Completeness | Clearly answers both 'what' (build production Airflow DAGs with best practices for operators, sensors, testing, deployment) and 'when' (explicit 'Use when' clause covering data pipelines, orchestrating workflows, scheduling batch jobs). | 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 would naturally use when needing this skill. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with 'Apache Airflow' and 'DAGs' as clear niche identifiers. Unlikely to conflict with general coding skills or other workflow tools due to the specific technology and terminology mentioned. | 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, but it's far too verbose for a SKILL.md file — it reads more like a tutorial or reference guide. The content would benefit enormously from splitting into separate files with the main skill serving as a concise overview with navigation links. Many of the patterns (basic dependency syntax, what idempotent means) are things Claude already knows.
Suggestions
Split the six patterns into a separate PATTERNS.md file and keep only the Quick Start example and a brief pattern index in SKILL.md
Remove the Core Concepts table explaining idempotent/atomic/incremental — Claude already knows these concepts
Add an explicit end-to-end workflow: write DAG → run `python dags/my_dag.py` to validate syntax → run tests → deploy, with validation checkpoints
Add navigation references like '**Testing**: See [TESTING.md](TESTING.md)' and '**Sensors**: See [SENSORS.md](SENSORS.md)' to achieve progressive disclosure
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose at ~400+ lines, with many patterns that are largely boilerplate code Claude already knows how to write. The 'Core Concepts' table explains basic principles (idempotent, atomic) that Claude understands. Six full patterns with complete code examples is excessive for a SKILL.md — most should be in separate reference files. | 1 / 3 |
Actionability | All code examples are fully executable, copy-paste ready Python with proper imports, realistic configurations, and complete DAG definitions. The testing pattern includes runnable pytest code, and the project structure is concrete. | 3 / 3 |
Workflow Clarity | Individual patterns are clear and well-sequenced (e.g., extract >> transform >> load), and error handling/retry patterns are shown. However, there's no explicit workflow for deploying or validating DAGs end-to-end (e.g., 'write DAG → test locally → validate → deploy'), and no verification checkpoints for the overall development process. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of content with no references to external files. All six patterns, the project structure, testing examples, and best practices are inlined. The common/ directory is shown in the project structure but never referenced as documentation. Content should be split into separate files (e.g., PATTERNS.md, TESTING.md) with the SKILL.md serving as an overview. | 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 | |
70444e5
Table of Contents
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.