agentleFS
Google CloudKnown publisherGoogleCloudPlatform/data-agent-kit-plugin/skills/gcp-managed-airflow-dag-authoring/SKILL.md

gcp-managed-airflow-dag-authoring

Skill240 starsChanged 5 months agoApache-2.0View on GitHub

Guides the authoring and validation of Apache Airflow DAGs for Managed Service for Apache Airflow (MSAA; formerly Cloud Composer). Covers environment context discovery, Airflow 2 vs 3 compatibility, authoring best practices, and local/remote validation processes. Use when creating or extending an Airflow DAG. Don't use when authoring Python code unrelated to Airflow DAGs.

The file

Show its rules and text

We split this skill into the rules it gives an agent

14 rules. About 0 are common, 7 are distinctive, and 7 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 7

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    If environment access is available: Use gcloud to inspect the environment (see Section 1.3).

    line 30
  2. Very specific:

    Check if composer-dev CLI is installed.

    line 38
  3. Very specific:

    Check if a local Python environment with airflow is available.

    line 39
  4. Distinctive:

    Run the following commands to discover version constraints:

    line 43
  5. Distinctive:

    Idempotency: Every task SHOULD be idempotent.

    line 75
  6. Distinctive:

    No Top-Level Code Execution: Do NOT execute database queries, external API calls, or heavy computations at the top level of the DAG file …

    line 78
  7. Very specific:

    Explicit Catchup: Always set catchup=False in the DAG definition unless historical backfilling is explicitly required.

    line 82
  8. Very specific:

    Use Airflow Variables/Connections: Never hardcode credentials or environment-specific configs.

    line 84
  9. Very specific:

    Use ruff or pylint if available.

    line 106
  10. Distinctive:

    If targeting Airflow 3, check with Airflow 3 rules if rulesets are available.

    line 112
  11. Very specific:

    If the user has composer-dev configured:

    line 117
  12. Distinctive:

    Only perform these steps if you have GCP access and are authorized to deploy to a target environment.

    line 133
  13. Distinctive:

    Wait 1-2 minutes for the scheduler to parse the file, then run:

    line 146
  14. Distinctive:

    Check for runtime parsing errors in Cloud Logging:

    line 168

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

GCP Managed Airflow DAG Authoring Guide

This skill guides you through authoring and validating Apache Airflow DAGs for Managed Service for Apache Airflow (MSAA; formerly Cloud Composer) environments.


Phase 1: Context Discovery

[!IMPORTANT] Before writing any DAG code, you MUST understand the constraints (e.g. version of Airflow) and capabilities of your target environment if user is willing to provide them.

1.1 Identify Target Environment & Access

Determine if you have direct access to the target Managed Airflow environment, local development environment or if you are working offline (only changing local files without validation).

  • If environment access is available: Use gcloud to inspect the environment (see Section 1.3).
  • If offline: Rely on user provided details.

1.2 Identify Development Environment

Determine if a local development environment is available.

  • Check if composer-dev CLI is installed.
  • Check if a local Python environment with airflow is available.

1.3 Inspect Target Environment (if available and requested)

Run the following commands to discover version constraints:

  1. Get Airflow/Image Version:

    gcloud composer environments describe <ENV_NAME> \
        --location <REGION> \
        --format="value(config.softwareConfig.imageVersion)"
  2. Get Installed Packages (Versions):

    gcloud composer environments describe <ENV_NAME> \
        --location <REGION> \
        --format="value(config.softwareConfig.pypiPackages)"
  3. Get DAGs GCS Bucket:

    gcloud composer environments describe <ENV_NAME> \
        --location <REGION> \
        --format="value(config.dagGcsPrefix)"

Phase 2: DAG Authoring Best Practices

2.1 General Airflow Best Practices

  • Idempotency: Every task SHOULD be idempotent. Running it multiple times with the same inputs (e.g., execution date) SHOULD produce the same result and not duplicate data.
  • No Top-Level Code Execution: Do NOT execute database queries, external API calls, or heavy computations at the top level of the DAG file (outside of tasks/operators). This code runs every few seconds during DAG parsing and will degrade performance.
  • Explicit Catchup: Always set catchup=False in the DAG definition unless historical backfilling is explicitly required.
  • Use Airflow Variables/Connections: Never hardcode credentials or environment-specific configs. Use Variable.get() (with deserialize_json=True if applicable) and BaseHook.get_connection(). Access variables via Jinja templates (e.g., {{ var.value.my_var }}) to avoid database calls during DAG parsing.

2.2 Airflow 2 vs Airflow 3 Compatibility

Reference @skill:gcp-managed-airflow-migrations to navigate adjusting the code to specific target Airflow version.


Phase 3: Validation Process

[!IMPORTANT] You MUST validate DAGs before concluding your task.

3.1 Local Validation (Offline/Pre-deployment)

3.1.1 Static Analysis & Linting

Use ruff or pylint if available.

ruff check path/to/dag.py
  • If targeting Airflow 3, check with Airflow 3 rules if rulesets are available.

3.1.2 Local Dev Environment (composer-dev)

If the user has composer-dev configured:

  1. Copy the DAG to the local directory with DAGs:

    cp path/to/dag.py $(composer-dev describe <LOCAL_ENV> --format="value(dags_directory)")
  2. Verify parsing:

    composer-dev run-airflow-cmd <LOCAL_ENV> dags list-import-errors

3.2: Target Environment Validation

Only perform these steps if you have GCP access and are authorized to deploy to a target environment.

3.2.1 Deploy to GCS

Upload the DAG to the target environment's GCS bucket:

gcloud storage cp path/to/dag.py gs://<TARGET_BUCKET>/dags/

3.2.2 Verify via Airflow CLI

Wait 1-2 minutes for the scheduler to parse the file, then run:

  1. Check for Import Errors:

    gcloud composer environments run <ENV_NAME> \
        --location <REGION> \
        dags list-import-errors

Pass Criteria: Output should be "No data found" or empty.

  1. Verify DAG is Listed:

    gcloud composer environments run <ENV_NAME> \
        --location <REGION> \
        dags list | grep <DAG_ID>

3.2.3 Monitor Cloud Logging

Check for runtime parsing errors in Cloud Logging:

resource.type="cloud_composer_environment"
resource.labels.environment_name="<ENV_NAME>"
log_id("airflow-scheduler")
severity>=ERROR
textPayload:"<DAG_FILE_NAME>"

Definition of Done

  • DAG code adheres to Airflow version constraints of the target environment.
  • DAG code follows best practices (no top-level execution, idempotent if possible).
  • DAG parses locally without import errors.
  • (If environment is available) DAG is deployed to the target environment and verified to have no import errors.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.