Review an Airflow DAG before production release, with interval semantics, replay safety, failure paths, verification gates, and rollback in one report.
A DAG can parse cleanly and still publish the wrong partition twice, hide an upstream failure behind a permissive leaf task, or turn a routine backfill into a downstream incident. This skill reviews the release contract around the code, not only the Python syntax.
It maps schedules to concrete data intervals, checks retry and replay behavior, traces branches and terminal state, reviews XCom and side effects, and sizes concurrency against pools, executors, and downstream limits. The result is a severity-ranked review with an explicit ready, ready-with-conditions, validate-first, or do-not-release verdict.
Use it before shipping a new DAG, changing its schedule or graph, upgrading Airflow, or replaying historical windows. The package does not connect to Airflow, trigger runs, create backfills, clear tasks, or invent test results. Missing runtime evidence stays visible in the verdict.
Input
Review this Airflow 3.3 DAG before release. It runs daily at 02:00 Europe/Warsaw, reads records using datetime.now(), appends to orders_daily, retries three times, and has catchup enabled from 2026-01-01. We may backfill 90 days. The load task has no unique key or staging publish step.
Output
A do-not-release verdict tied to interval drift and duplicate-write risk; a concrete interval-to-partition contract; an idempotent staging and publish repair; a 90-day concurrency and downstream-capacity review; boundary, retry, and replay tests; and a backfill plan that requires current-run inventory before creation.
Input
Review this Airflow 3.3 customer export DAG. A branch skips either full_export or delta_export. Both feed cleanup with trigger_rule=all_done, and cleanup is the only leaf task. Cleanup deletes temporary files and usually succeeds. Alerts fire only when the DAG run fails.
Provide the DAG and imported local modules, Airflow and provider versions, schedule and timezone, data inputs and outputs, executor and concurrency settings, deployment method, and any test or run evidence you have. State whether this is a new release, change, upgrade, incident repair, or planned backfill. The skill returns a DAG contract, evidence map, prioritized findings, patch sequence, verification matrix, and release and recovery plan without executing live Airflow operations.
The DAG file and imported local modules. Dependency locks or the installed Airflow and provider versions are needed for a compatibility verdict.
Schedule, timezone, start date, catchup policy, input and output partitions or keys, late-data behavior, and replay expectations when known.
Executor, pools, queues, worker limits, connections, deployment method, monitoring, current run state, and rollback path. Missing evidence can remain explicit.
SKILL.md; Airflow DAG contract and release-review workflow; severity rubric; finding schema; verification matrix; deployment, backfill, and rollback template; Agent Skills interface metadata
No reviews yet.
Output
A do-not-release verdict; graph-path analysis showing how the successful all_done leaf can mask an export failure; a corrected terminal-state design; cleanup changes that preserve diagnostic evidence; and tests for full, delta, skipped, failed, and cleanup-failed paths.
Input
We are moving a DAG from Airflow 2.8 to 3.3. It uses PythonOperator, context['execution_date'], ExternalTaskSensor in poke mode, and returns a pandas DataFrame through XCom. KubernetesExecutor has 20 worker slots. We need to replay six months after the upgrade, but no staging output is attached.
Output
A validate-first or do-not-release verdict based on the supplied compatibility gaps; a version-bound import and context review; durable-storage replacement for the DataFrame payload; sensor and capacity decisions tied to installed providers; upgrade and replay verification matrices; and separate code rollback and data-repair plans without claiming unrun tests passed.
Creator
Oorvane4
