Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/apache/airflow/airflow-new-sdknpx skills add apache/airflow --skill airflow-new-sdkgit clone --depth 1 https://github.com/apache/airflowWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/apache/airflow/airflow-new-sdk)<a href="https://agentmods.dev/skills/apache/airflow/airflow-new-sdk"><img src="https://agentmods.dev/badge/skills/apache/airflow/airflow-new-sdk.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00127 | $0.01695 |
| Opus 5 | $0.00063 | $0.00847 |
| Sonnet 5 | $0.00025 | $0.00339 |
| Haiku 4.5 | $0.00013 | $0.00169 |
Grade A, and why
airflow-new-sdk scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 161 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Implementing a new language SDK for Airflow
Start here
Read contributing-docs/30_new_language_sdk.rst first. It is the
authoritative contributor guide for this topic — coordinator base class choices,
wire protocol spec, bundle footer format, and testing requirements. Everything
in this skill builds on top of it, not alongside it.
Repository layout
Every new SDK needs two things. The coordinator (Python) goes here:
task-sdk/src/airflow/sdk/coordinators/<language>/
__init__.py # re-export + module docstring
coordinator.py # subclass of SubprocessCoordinator or BaseCoordinator
task-sdk/tests/coordinators/<language>/
test_coordinator.py
task-sdk/tests/integration/coordinators/<language>/
test_integration.py # requires Breeze
The language SDK itself lives in a top-level <language>-sdk/ directory (like
java-sdk/ and go-sdk/). For native-executable languages using
ExecutableCoordinator, no coordinator code is needed at all.
Choosing the right base class — quick guide
Does the runtime compile to a self-contained native executable?
YES → Use ExecutableCoordinator (zero Python to write).
Append an AFBNDL01 footer with a packer tool (see go-sdk reference).
NO →
Does it start via a single shell command (node, ruby, dotnet, …)?
YES → Subclass SubprocessCoordinator.
Implement _build_execute_task_command only (see 30_new_language_sdk.rst).
NO →
Subclass BaseCoordinator and implement execute_task from scratch.
(Rare: gRPC daemons, shared memory, persistent processes.)
The full rationale, method signature, and socket lifecycle for each path are in
30_new_language_sdk.rst. Read that section before writing any code.
Reference implementations to study
| What to study | Where |
|---|---|
| SubprocessCoordinator base class | task-sdk/src/airflow/sdk/coordinators/_subprocess.py |
| Java coordinator (SubprocessCoordinator subclass) | task-sdk/src/airflow/sdk/coordinators/java/coordinator.py |
| ExecutableCoordinator (native bundles) | task-sdk/src/airflow/sdk/coordinators/executable/coordinator.py |
| Wire protocol in Kotlin | java-sdk/sdk/src/main/kotlin/org/apache/airflow/sdk/execution/ |
| Wire protocol in Go | go-sdk/pkg/execution/ |
| AFBNDL01 footer (Go reference) | go-sdk/internal/bundlefooter/, task-sdk/docs/executable-bundle-spec.rst |
| All message types and field specs | task-sdk/src/airflow/sdk/execution_time/schema/schema.json |
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 161 lines · 127 tokens per session scan A f098050628df
airflow-new-sdk is a skill published in the GitHub repository apache/airflow (46,687 stars, last pushed yesterday), licensed Apache-2.0. It adds 127 tokens to every session and 1,695 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
airflow-workflow
Execution guide for Airflow scheduled jobs — troubleshooting, updating, connid conventions, and cron references.
development
开发语言能力索引。Python、Go、Rust、TypeScript、Java、C++、Shell。当用户提到编程、开发、代码、语言时路由到此。.
authoring-java-sdk-tasks
Writes Airflow task logic in Java, Kotlin, or any JVM language using the Airflow Java SDK. Use when the user wants to implement Airflow tasks in Java/JVM, asks about @Builder.Dag/@Builder.Task/@Builder.XCom, the Task/BundleBuilder interfaces, reading connections/variables/XComs from Java, the JSON-to-Java type…
configuring-airflow-language-sdks
Configures Airflow to run language SDK tasks (Java, Go, and future native SDKs) — register a coordinator, map a queue to it, ensure the runtime/artifact on workers, and tune coordinator options. Use when the user wants Airflow to route a queue to a native-language coordinator, asks about the [sdk]…
authoring-go-sdk-tasks
Writes Airflow task logic in Go using the Airflow Go SDK. Use when the user wants to implement Airflow tasks in Go, asks about BundleProvider/RegisterDags, the bundlev1 Registry/Dag interfaces, registering Go tasks (AddTask/AddTaskWithName), dependency injection by parameter type (context.Context, sdk.TIRunContext…
authoring-language-sdk-tasks
The language-neutral foundation for Airflow language SDKs — implement task logic in a non-Python language while the DAG stays in Python. Use when the user wants to run an Airflow task in another language (Java, Kotlin, Go, or other JVM/native languages), asks how the Python @task.stub pairs with native task code, how…