Core Dagster Concepts
Brief definitions only (see reference files for detailed examples):
- Asset: Persistent object (table, file, model) produced by your pipeline
- Component: Reusable building block that generates definitions (assets, schedules, sensors, jobs, etc.) relevant to a particular domain.
Integration Workflow
When integrating with ANY external tool or service, read the Integration libraries index. This contains information about which integration libraries exist, and references on how to create new custom integrations for tools that do not have a published library.
dg CLI
The dg CLI is the recommended way to programmatically interact with Dagster (adding definitions, launching runs, exploring project structure, etc.). It is installed as part of the dagster-dg-cli package. If a relevant CLI command for a given task exists, always attempt to use it.
ONLY explore the existing project structure if it is strictly necessary to accomplish the user's goal. In many cases, existing CLI tools will have sufficient understanding of the project structure, meaning listing and reading existing files is wasteful and unnecessary.
Almost all dg commands that return information have a --json flag that can be used to get the information in a machine-readable format. This should be preferred over the default table output unless you are directly showing the information to the user.
UV Compatibility
Projects typically use uv for dependency management, and it is recommended to use it for dg commands if possible:
uv run dg list defs
uv run dg launch --assets my_asset
CRITICAL: Always Read Reference Files Before Answering
NEVER answer from memory or guess at CLI commands, APIs, or syntax. ALWAYS read the relevant reference file(s) from the Reference Index below before responding.
For every question, identify which reference file(s) are relevant using the index descriptions, read them, then answer based on what you read.
Reference Index
- Asset Selection Syntax — filtering assets by tag, group, kind, upstream, or downstream; AssetSelection in Python, UI search bar, or CLI
- Environment Variables — configuring environment variables across different environments
- Asset Patterns — defining assets, dependencies, metadata, partitions, or multi-asset definitions
- Choosing an Automation Approach — deciding between schedules, sensors, and declarative automation
- Schedules — time-based automation with cron expressions
- Declarative Automation — asset-centric condition-based automation using AutomationCondition
- Asset Sensors — triggering on asset materialization events
- Basic Sensors — event-driven automation with file watching or custom polling
- Run Status Sensors — reacting to run success, failure, or other status changes
- dg check — validating project configuration or definitions
- create-dagster — creating a new Dagster project from scratch
- dg dev — starting a local Dagster development instance
- dg launch — materializing assets or executing jobs locally
- dg list components — seeing available component types for scaffolding
- dg list defs — listing or filtering registered definitions
- Dagster Plus API — dg api, programmatically querying or managing Dagster Plus resources (assets, runs, deployments, code locations, schedules, sensors, secrets, issues, etc.)
- dg list — exploring project structure (component tree, environment variables, workspace projects)
- Dagster Plus CLI — dg plus, Dagster Plus authentication, configuration, and deployment; logging in, setting config, creating API tokens, deploying code, pulling env vars, managing dbt manifests
- dg scaffold component — creating a custom reusable component type
- dg scaffold defs — adding new definitions (assets, schedules, sensors, components) to a project
- dg utilities — dg utils, inspecting component types, viewing integrations, refreshing state-backed component cache
- Creating Components — building a new custom component from scratch
- Designing Component Integrations — designing a component that wraps an external service or tool; custom integrations
- Resolved Framework — defining custom YAML schema types using Resolver, Model, or Resolvable
- Subclassing Components — extending an existing component via subclassing; customize dagster integration component
- Template Variables — using Jinja2 template variables in component YAML (env, dg, context, or custom scopes)
- Creating State-Backed Components — building a component that fetches and caches external state
- Using State-Backed Components — managing state-backed components in production, CI/CD, or refreshing state
- Deployment Configuration Files — build.yaml, container_context.yaml, dagster_cloud.yaml; Dagster Plus deployment configuration; configuring Docker registry, container context, agent queue; Hybrid deployment files
- Integration libraries index for 40+ tools and technologies (dbt, Fivetran, Snowflake, AWS, etc.). — integration, external tool, dagster-*; dbt, fivetran, airbyte, snowflake, bigquery, sling, aws, gcp
- Migration Guides — sensor migration to declarative automation, sensor migration to automation condition
1---2name: dagster-expert3description: This skill should be used for Dagster project work involving assets, components, integrations, or the dg CLI; it requires consulting the bundled command and API references before proposing implementation details.4---56## Core Dagster Concepts78Brief definitions only (see reference files for detailed examples):910- **Asset**: Persistent object (table, file, model) produced by your pipeline11- **Component**: Reusable building block that generates definitions (assets, schedules, sensors, jobs, etc.) relevant to a particular domain.1213## Integration Workflow1415When integrating with ANY external tool or service, read the [Integration libraries index](./references/integrations/INDEX.md). This contains information about which integration libraries exist, and references on how to create new custom integrations for tools that do not have a published library.1617## dg CLI1819The `dg` CLI is the recommended way to programmatically interact with Dagster (adding definitions, launching runs, exploring project structure, etc.). It is installed as part of the `dagster-dg-cli` package. If a relevant CLI command for a given task exists, always attempt to use it.2021ONLY explore the existing project structure if it is strictly necessary to accomplish the user's goal. In many cases, existing CLI tools will have sufficient understanding of the project structure, meaning listing and reading existing files is wasteful and unnecessary.2223Almost all `dg` commands that return information have a `--json` flag that can be used to get the information in a machine-readable format. This should be preferred over the default table output unless you are directly showing the information to the user.2425## UV Compatibility2627Projects typically use `uv` for dependency management, and it is recommended to use it for `dg` commands if possible:2829```bash30uv run dg list defs31uv run dg launch --assets my_asset32```3334## CRITICAL: Always Read Reference Files Before Answering3536NEVER answer from memory or guess at CLI commands, APIs, or syntax. ALWAYS read the relevant reference file(s) from the Reference Index below before responding.3738For every question, identify which reference file(s) are relevant using the index descriptions, read them, then answer based on what you read.3940## Reference Index4142<!-- BEGIN GENERATED INDEX -->4344- [Asset Selection Syntax](./references/asset-selection.md) — filtering assets by tag, group, kind, upstream, or downstream; AssetSelection in Python, UI search bar, or CLI45- [Environment Variables](./references/env-vars.md) — configuring environment variables across different environments46- [Asset Patterns](./references/assets/INDEX.md) — defining assets, dependencies, metadata, partitions, or multi-asset definitions47- [Choosing an Automation Approach](./references/automation/choosing-automation.md) — deciding between schedules, sensors, and declarative automation48- [Schedules](./references/automation/schedules.md) — time-based automation with cron expressions49- [Declarative Automation](./references/automation/declarative-automation/INDEX.md) — asset-centric condition-based automation using AutomationCondition50- [Asset Sensors](./references/automation/sensors/asset-sensors.md) — triggering on asset materialization events51- [Basic Sensors](./references/automation/sensors/basic-sensors.md) — event-driven automation with file watching or custom polling52- [Run Status Sensors](./references/automation/sensors/run-status-sensors.md) — reacting to run success, failure, or other status changes53- [dg check](./references/cli/check.md) — validating project configuration or definitions54- [create-dagster](./references/cli/create-dagster.md) — creating a new Dagster project from scratch55- [dg dev](./references/cli/dev.md) — starting a local Dagster development instance56- [dg launch](./references/cli/launch.md) — materializing assets or executing jobs locally57- [dg list components](./references/cli/list-components.md) — seeing available component types for scaffolding58- [dg list defs](./references/cli/list-defs.md) — listing or filtering registered definitions59- [Dagster Plus API](./references/cli/api/INDEX.md) — dg api, programmatically querying or managing Dagster Plus resources (assets, runs, deployments, code locations, schedules, sensors, secrets, issues, etc.)60- [dg list](./references/cli/list/INDEX.md) — exploring project structure (component tree, environment variables, workspace projects)61- [Dagster Plus CLI](./references/cli/plus/INDEX.md) — dg plus, Dagster Plus authentication, configuration, and deployment; logging in, setting config, creating API tokens, deploying code, pulling env vars, managing dbt manifests62- [dg scaffold component](./references/cli/scaffold/component.md) — creating a custom reusable component type63- [dg scaffold defs](./references/cli/scaffold/defs.md) — adding new definitions (assets, schedules, sensors, components) to a project64- [dg utilities](./references/cli/utils/INDEX.md) — dg utils, inspecting component types, viewing integrations, refreshing state-backed component cache65- [Creating Components](./references/components/creating-components.md) — building a new custom component from scratch66- [Designing Component Integrations](./references/components/designing-component-integrations.md) — designing a component that wraps an external service or tool; custom integrations67- [Resolved Framework](./references/components/resolved-framework.md) — defining custom YAML schema types using Resolver, Model, or Resolvable68- [Subclassing Components](./references/components/subclassing-components.md) — extending an existing component via subclassing; customize dagster integration component69- [Template Variables](./references/components/template-variables.md) — using Jinja2 template variables in component YAML (env, dg, context, or custom scopes)70- [Creating State-Backed Components](./references/components/state-backed/creating.md) — building a component that fetches and caches external state71- [Using State-Backed Components](./references/components/state-backed/using.md) — managing state-backed components in production, CI/CD, or refreshing state72- [Deployment Configuration Files](./references/deployment/config-files.md) — build.yaml, container_context.yaml, dagster_cloud.yaml; Dagster Plus deployment configuration; configuring Docker registry, container context, agent queue; Hybrid deployment files73- [Integration libraries index for 40+ tools and technologies (dbt, Fivetran, Snowflake, AWS, etc.).](./references/integrations/INDEX.md) — integration, external tool, dagster-\*; dbt, fivetran, airbyte, snowflake, bigquery, sling, aws, gcp74- [Migration Guides](./references/migration/INDEX.md) — sensor migration to declarative automation, sensor migration to automation condition75<!-- END GENERATED INDEX -->