- 📁 references/
- 📄 SKILL.md
dagster-expert
Expert guidance for working with Dagster and the dg CLI. ALWAYS use before doing any task that requires knowledge specific to Dagster, or that references assets, materialization, components, data tools or data pipelines. Common tasks may include creating a new project, adding new definitions, understanding the current project structure, answering general questions about the codebase (finding asset, schedule, sensor, component or job definitions), debugging issues, or providing deep information about a specific Dagster concept. --- ## 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: ```bash uv run dg list defs uv run dg launch --assets my_asset ``` ## 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. ## CRITICAL: Always Read Reference Files Before Answering NEVER answer from memory or guess at CLI commands, APIs, or syntax
