ClaudeSuperPower
SubmitLog in

migrating-dagster-to-airflow

Skill

Guide for migrating Dagster projects to Apache Airflow 3 on Astro. Use when the user mentions migrating, converting, or porting Dagster (or Dagster+) code to Airflow or Astro, wants to plan or assess such a migration, or asks what a Dagster construct maps to in Airflow. Covers assets, partitions, sc

412Data Engineering

Install

git clone https://github.com/astronomer/agents.git ~/.claude/skills/migrating-dagster-to-airflow

What is migrating-dagster-to-airflow?

Guide for migrating Dagster projects to Apache Airflow 3 on Astro. Use when the user mentions migrating, converting, or porting Dagster (or Dagster+) code to Airflow or Astro, wants to plan or assess such a migration, or asks what a Dagster construct maps to in Airflow. Covers assets, partitions, schedules, sensors, declarative automation, resources, IO managers, ops/jobs, dbt, Pipes, Components, and Dagster+ platform config. Always load this skill as the first step for any Dagster-to-Airflow request.

What this can do

Capabilities declared in this component's own frontmatter — not inferred.

Inherit all session tools

Declares no tool restrictions — inherits every session tool

~127 tokens of context used while enabled, before you invoke anything

Trust

87/100 · Excellent

2 factors scored below maximum

Documentation

README · ~9 min read

Dagster → Airflow 3 (Astro) migration

Migrate a Dagster project to Airflow 3 on Astro Runtime, honestly. The migration is asset-first (Dagster asset graphs translate to Airflow assets and asset-aware schedules, not flattened DAGs), incremental (domain by domain, Dagster stays authoritative until parity), and honest (every definition gets an explicit disposition; semantic deltas are documented, never papered over).

First time driving this? Read reference/quickstart.md first: hour-one commands, the glossary, and what can and cannot break.

Migration at a glance

  1. Baseline the source project's tests, then inventory it read-only (scripts/inventory.py → manifest).
  2. Review classifications (MECH/JUDG/REDESIGN/NONE per reference/mapping.md); make the go/no-go call (three outcomes; migrate-with-conditions is the common case, stay is the narrow one); plan DAG boundaries, per-edge IO decisions, and Gate 3 expectations into the manifest.
  3. Trial-migrate 2-3 representative units end-to-end through every validation gate.
  4. Migrate domain by domain through the six-gate ladder (reference/validation.md), tracking per-unit state (scripts/status.py); fix failure classes via reference/troubleshooting.md, never stub.
  5. Map the platform layer (secrets, alerts, CI/CD, Deployments) per reference/astro-deployment.md.
  6. Run side by side, then cut over per domain (consumers unpause first; see the checklist), keeping rollback one step away.

Reviews

Log in to leave a review.

No reviews yet — be the first.

Explore related

Other things in this space — across every part of the ecosystem, not just skills.

Subagents

All subagents →

code-architect

Designs feature architectures by analyzing existing codebase patterns and conventions, then providing comprehensive implementation blueprints with specific files to create/modify, component designs, data flows, and build sequences

32.8K stars

plugin-validator

Use this agent when the user asks to "validate my plugin", "check plugin structure", "verify plugin is correct", "validate plugin.json", "check plugin files", or mentions plugin validation. Also trigger proactively after user creates or modifies plugin components. Examples: <example> Context: User f

32.8K stars

scan-inventory

Restricted read-only repository cartographer dispatched by the Claude Security scan workflow to partition the tree into components and account for every top-level directory; not for direct invocation or vulnerability research.

32.8K stars