---

name: providers-extensions description: "Work with Airflow providers, standard operators/sensors/hooks, custom extensions, provider metadata, and provider package maintenance conventions." disable-model-invocation: true metadata: disco-role: operating license: Apache 2.0

Providers and Extensions

Use this sub-skill when a task involves Airflow providers or extension points: selecting provider packages/extras, importing standard operators/sensors/hooks in Dags, writing custom operators/hooks/sensors, registering plugins/listeners/timetables/notifiers/extra links, or maintaining provider package metadata.

Route First

• For general Dag authoring, TaskFlow, task mapping, assets, schedules, or airflow.sdk basics, use ../authoring-task-sdk/ first and return here only for provider-specific imports or extension classes.
• For CLI, Breeze, CI, release preparation, or broad provider-release classification workflows, use ../contribution-tooling/; this sub-skill only covers the provider files and safe metadata checks needed during ordinary development.
• For REST API, web UI internals, scheduler, executor, Helm, Docker, or deployment behavior, use the corresponding sibling sub-skill rather than treating providers as a catch-all.
• For cloud-service-specific APIs, prefer the relevant provider’s own documentation or source; this sub-skill covers Airflow provider conventions and the standard provider patterns, not deep SDK behavior for every integration.

What To Read

• references/provider-api-patterns.md for public extension boundaries, standard provider imports, operator/sensor/hook patterns, package naming, extras, and provider entry points.
• references/extension-workflows.md for recipes for custom operators, hooks, sensors, plugins, listeners, timetables, notifiers, extra links, and provider-package tests.
• references/provider-metadata.md for provider.yaml, get_provider_info, pyproject.toml, generated-file cautions, docs/changelog rules, and the bundled checker.
• references/troubleshooting.md for missing provider packages, import errors, connection IDs, deferrable trigger dependencies, generated-file mistakes, and docs/changelog pitfalls.

Fast Guidance

• Install/import provider-specific code explicitly. Airflow core does not guarantee that every provider is installed; standard operators such as BashOperator and FileSensor live in apache-airflow-providers-standard.
• Use public bases for new runtime code: airflow.sdk.BaseOperator, airflow.sdk.BaseSensorOperator, airflow.sdk.BaseHook, airflow.sdk.BaseNotifier, airflow.sdk.BaseOperatorLink, and documented plugin/listener/timetable APIs.
• Keep expensive work out of operator constructors. Resolve hooks, connections, network clients, and service jobs inside execute, poke, trigger code, or helper methods called from execution.
• Treat provider.yaml as the human-edited source for provider metadata. get_provider_info.py, provider docs indexes, and most provider pyproject.toml content are generated; edit only the preserved dependency sections unless the generation workflow says otherwise.
• Before touching provider metadata, run scripts/check_provider_metadata.py --provider-dir <provider-dir> against the provider directory you are editing and fix reported errors before relying on generated files.

Done Criteria

A provider/extension change is ready when imports come from installed provider packages, custom classes use public extension points, metadata and entry points agree, generated files are not hand-edited incorrectly, and tests cover the changed operator/hook/sensor/plugin behavior without depending on external services unless explicitly mocked or isolated.