Setting Up Astro Project
Initialize an Astro CLI Airflow project with standard folders, Dockerfile, and dependency files before writing DAGs or starting local dev.
Overview
Setting Up Astro Project is an agent skill for the Build phase that initializes and configures Astro CLI Airflow project structure, dependencies, and connections context before local env or DAG authoring.
Install
npx skills add https://github.com/astronomer/agents --skill setting-up-astro-projectWhat is this skill?
- Runs astro dev init to create dags/, include/, plugins/, tests/, Dockerfile, and packages.txt layout
- Avoids pinning --airflow-version or --runtime-version unless explicitly requested
- Points to managing-astro-local-env for running locally and authoring-dags for DAG work
- Documents open-source Apache Airflow Docker Compose and Helm paths when not on Astro
- Chains forward to deploying-airflow for production deployment strategies
- Default bootstrap via astro dev init without version flags unless user-requested
Adoption & trust: 730 installs on skills.sh; 384 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need scheduled data pipelines but lack a correct Astro/Airflow repo layout, dependency files, and clear next steps for local run versus deployment.
Who is it for?
Builders adopting Astronomer Astro who want a latest-runtime default init without manual directory guesswork.
Skip if: Writing individual DAG task logic, tuning production cluster sizing, or teams already mid-migration with pinned legacy runtime requirements.
When should I use this skill?
User wants to create a new Astro/Airflow project, set up dependencies, configure connections or variables, or understand Astro project structure.
What do I get? / Deliverables
You get an initialized Astro project tree and guidance to invoke managing-astro-local-env and authoring-dags next—or Airflow Docker/Helm paths if you are not on Astro.
- Initialized Astro project directory tree
- Dockerfile and dependency manifest baseline
- Pointers to local env and DAG authoring follow-on skills
Recommended Skills
Journey fit
Project scaffolding belongs in Build when you are implementing data orchestration infrastructure for your product. Backend covers pipeline runtimes and job orchestration that power product data flows, not front-end UI work.
How it compares
Scaffolding skill for Astro CLI repos—not a substitute for the authoring-dags or deploying-airflow skills in the same bundle.
Common Questions / FAQ
Who is setting-up-astro-project for?
Solo builders and small data teams starting Airflow work on Astro CLI who need standard project folders and Dockerfile-driven runtime discovery.
When should I use setting-up-astro-project?
Use it in Build when creating a new Astro project, configuring dependencies, connections, or variables, or understanding repo layout before local dev or DAG authoring.
Is setting-up-astro-project safe to install?
It instructs CLI and filesystem changes in your repo; review the Security Audits panel on this Prism page and run init only in trusted directories.
Workflow Chain
Then invoke: managing astro local env, authoring dags
SKILL.md
READMESKILL.md - Setting Up Astro Project
# Astro Project Setup This skill helps you initialize and configure Airflow projects using the Astro CLI. > **To run the local environment**, see the **managing-astro-local-env** skill. > **To write DAGs**, see the **authoring-dags** skill. > **Open-source alternative:** If the user isn't on Astro, guide them to Apache Airflow's Docker Compose quickstart for local dev and the Helm chart for production. For deployment strategies, use the `deploying-airflow` skill. --- ## Initialize a New Project ```bash astro dev init ``` > **Don't pass `--airflow-version` or `--runtime-version` unless the user explicitly asks for a specific pin.** Plain `astro dev init` resolves to the latest Astro Runtime — that's the right default. Specifying a version risks pinning to a stale value from training data. If the user wants to know what was installed, read the generated `Dockerfile` afterward instead of guessing. Creates this structure: ``` project/ ├── dags/ # DAG files ├── include/ # SQL, configs, supporting files ├── plugins/ # Custom Airflow plugins ├── tests/ # Unit tests ├── Dockerfile # Image customization ├── packages.txt # OS-level packages ├── requirements.txt # Python packages └── airflow_settings.yaml # Connections, variables, pools ``` --- ## Adding Dependencies ### Python Packages (requirements.txt) ``` apache-airflow-providers-snowflake==5.3.0 pandas==2.1.0 requests>=2.28.0 ``` ### OS Packages (packages.txt) ``` gcc libpq-dev ``` ### Custom Dockerfile For complex setups (private PyPI, custom scripts): ```dockerfile FROM quay.io/astronomer/astro-runtime:12.4.0 RUN pip install --extra-index-url https://pypi.example.com/simple my-package ``` **After modifying dependencies:** Run `astro dev restart` --- ## Configuring Connections & Variables ### airflow_settings.yaml Loaded automatically on environment start: ```yaml airflow: connections: - conn_id: my_postgres conn_type: postgres host: host.docker.internal port: 5432 login: user password: pass schema: mydb variables: - variable_name: env variable_value: dev pools: - pool_name: limited_pool pool_slot: 5 ``` ### Export/Import ```bash # Export from running environment astro dev object export --connections --file connections.yaml # Import to environment astro dev object import --connections --file connections.yaml ``` --- ## Validate Before Running Parse DAGs to catch errors without starting the full environment: ```bash astro dev parse ``` --- ## Related Skills - **managing-astro-local-env**: Start, stop, and troubleshoot the local environment - **authoring-dags**: Write and validate DAGs (uses MCP tools) - **testing-dags**: Test DAGs (uses MCP tools) - **deploying-airflow**: Deploy DAGs to production (Astro, Docker Compose, Kubernetes)