Agent skill

Authoring Language SDK Tasks

by astronomer in astronomer/agents

The language-neutral foundation for Airflow language SDKs — implement task logic in a non-Python language while the DAG stays in Python.

Apache-2.0Auto-check passedData & Analytics

Install Authoring Language SDK Tasks

skills CLI
$ npx skills add astronomer/agents --skill authoring-language-sdk-tasks -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install astronomer/agents authoring-language-sdk-tasks --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/astronomer/agents.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/authoring-language-sdk-tasks .claude/skills/authoring-language-sdk-tasks && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
authoring-language-sdk-tasks
GitHub stars
451
Token cost
~1.8k tokens
SKILL.md length
860 words
Files
1
Skills in repo
34
Repo updated
First seen
Licence
Apache-2.0

At a glance

The language-neutral foundation for Airflow language SDKs — implement task logic in a non-Python language while the DAG stays in Python.

  • Works in 2 steps: A Python stub in a normal DAG file — no… → A native implementation (Java, Go, etc.)…
  • The user wants to run an Airflow task in another language (Java
  • SKILL.md covers The model, The two-sided model, The XCom-as-JSON contract and What is language-specific (and…, plus 3 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Authoring Language SDK Tasks is an agent skill from astronomer/agents. 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 task/DAG IDs must match across the two sides, how data passes via XCom as JSON, or which language SDKs exist. This skill owns the shared Python-stub pattern and conceptual model; for a specific…

Its SKILL.md is about 1.8k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Data & Analytics, covering Data pipelines and ETL and Android development. It works with Python, Java, Apache Airflow and Kotlin. The repository describes itself as: AI agent tooling for data engineering workflows. The licence is Apache-2.0.

When your agent uses it

  • The user wants to run an Airflow task in another language (Java
  • Other JVM/native languages)
  • Asks how the Python @task.stub pairs with native task code
  • How task/DAG IDs must match across the two sides

Example prompts

  • “s native API, build, and runtime, use that language”
  • “/authoring-language-sdk-tasks”

Requirements

  • Python 3

Workflow steps

2 steps, taken from the first numbered list in SKILL.md.

  1. A Python stub in a normal DAG file — no logic; it declares the task, its queue, the dependency graph, and retry policy.
  2. A native implementation (Java, Go, etc.) whose IDs match the Python side and where the work happens.

What it can do on your machine

Read from SKILL.md and the folder at commit 486ee63. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are python).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Authoring Language SDK Tasks loads about 1.8k tokens when it runs. Until then it costs about 167 tokens; SKILL.md has 860 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~167
When it runs · the whole SKILL.md, loaded when a task matches
~1.8k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from astronomer/agents at commit 486ee63, republished under its Apache-2.0 licence (© astronomer). 860 words, ~1,827 tokens.

Download SKILL.mdSave it as .claude/skills/authoring-language-sdk-tasks/SKILL.md (or your agent's skills folder).
name
authoring-language-sdk-tasks
description
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 task/DAG IDs must match across the two sides, how data passes via XCom as JSON, or which language SDKs exist. This skill owns the shared Python-stub pattern and conceptual model; for a specific language's native API, build, and runtime, use that language's skill (e.g. authoring-java-sdk-tasks, authoring-go-sdk-tasks).

Authoring Language SDK Tasks (Shared Foundation)

Airflow language SDKs let you implement task logic in a language other than Python while the DAG and its scheduling stay in Python. This skill describes the parts that are identical across every language SDK. Each language has its own companion skill for the native API, build tooling, and runtime — see Per-language skills.

Experimental. The language SDKs are in preview. APIs and artifact coordinates may change.


The model

A DAG is authored in Python as usual. Tasks that should run in another language are declared as stubs routed to a dedicated queue. At runtime, Airflow hands a stub task to a coordinator that launches a short-lived native subprocess for that one task instance, runs your compiled/native code, and shuts the subprocess down.

Consequences that hold for every language SDK:

  • One subprocess per task instance — there is no shared in-process state between task instances. Pass data via XCom or an external store.
  • The DAG, schedule, retries, and queue routing live in Python. The native side only implements task logic.
  • Data crossing the boundary is JSON. See The XCom-as-JSON contract.

The two-sided model

Every task has two halves that must agree:

  1. A Python stub in a normal DAG file — no logic; it declares the task, its queue, the dependency graph, and retry policy.
  2. A native implementation (Java, Go, etc.) whose IDs match the Python side and where the work happens.
Python side (scheduling)

The example below uses the Go SDK to be concrete, but the Python side is identical for every language SDK. The queue name ("golang" here) is an arbitrary label you choose — it just has to match a key in queue_to_coordinator (see configuring-airflow-language-sdks). Pick whatever name fits the SDK you're routing to.

python
from datetime import timedelta
from airflow.sdk import dag, task


@dag
def sales_pipeline():
    @task.stub(queue="golang")          # queue selects the coordinator (see configuring-airflow-language-sdks)
    def extract(): ...

    @task.stub(queue="golang")
    def transform(extracted): ...        # arg only declares the dependency

    @task.stub(queue="golang", retries=1, retry_delay=timedelta(seconds=5))
    def load(transformed): ...

    @task()                              # an ordinary Python task can sit downstream
    def report(loaded):
        print(f"done: {loaded}")

    report(load(transform(extract())))


sales_pipeline()

Rules that apply regardless of language:

  • The stub function name is the task ID and the @dag name (or dag_id=) is the DAG ID. The native side must use these exact IDs.
  • An upstream argument on a stub (e.g. transform(extracted)) exists only to declare the dependency in Python. The value itself is fetched on the native side via XCom — passing it in Python does not hand it to the native code.
  • Queue, retries, and other task arguments are set on the stub, not in the native code. A native task that fails is reported back to Airflow, which then applies the stub's retry policy.
  • The queue value is what routes the task to a coordinator; the same string must appear in queue_to_coordinator (see configuring-airflow-language-sdks).

The XCom-as-JSON contract

XCom values are stored as JSON in Airflow's metadata database, so the boundary between Python and any native language is JSON. The Python/JSON side is the same for every SDK:

Python typeJSON
intnumber (integer)
floatnumber (decimal)
strstring
boolboolean
Nonenull
listarray
dictobject

Each language SDK maps these JSON types onto its own native types (e.g. a JSON integer becomes a Java Long). The native-type mapping lives in that language's skill. The key portability rule: a value pushed by one task is read by another as JSON, so the consuming side must expect a type compatible with what was stored.


Show full SKILL.md (337 more words)Show less

What is language-specific (and lives elsewhere)

This skill deliberately stops at the shared concepts. The following differ per language and are documented in each language's companion skills:

  • Native task API — how you declare tasks, read connections/variables/XComs, and push results (annotations, interfaces, function registration, etc.).
  • Native type mapping — the native column of the JSON table above.
  • Build and packaging — how the artifact is compiled and bundled.
  • Runtime prerequisite — what must be present on the worker (a language runtime for some SDKs, e.g. a JRE for the Java SDK; none for the Go SDK's self-contained bundles).

The Airflow-side wiring (which coordinator runs which queue) is shared in structure but has per-coordinator options; it lives in configuring-airflow-language-sdks.


Language-agnostic pitfalls

  • IDs must match exactly across the Python stub function name and the native task ID, and across @dag/dag_id and the native DAG ID. Mismatches surface as "no DAGs" or missing-XCom errors.
  • Both sides need the upstream reference. Python declares the dependency by passing the upstream call; the native code retrieves the value via XCom.
  • Set queue and retries on the stub, never in the native code.
  • Stub bodies must be empty. An AST check enforces it — only pass, ..., or a docstring is allowed in the body; any real logic is rejected.
  • retry_policy is rejected on stubs (@task.stub raises ValueError). Use retries/retry_delay instead — a retry-policy callable runs Python in-process and would never fire for a task executing in a native subprocess.
  • Assets, deferral, and some other Airflow features have limited or no support in the language SDKs today.

Per-language skills

  • authoring-java-sdk-tasks: Java/Kotlin/JVM native API, type mapping, and logging.
  • authoring-go-sdk-tasks: Go native API — task registration, dependency injection by parameter type, and client access.
  • (Future language SDKs each add their own authoring-<lang>-sdk-tasks skill that builds on this one.)
  • configuring-airflow-language-sdks: Route a queue to a coordinator and set runtime options.
  • authoring-dags: General Airflow DAG authoring (the Python side lives here too).
  • deploying-java-sdk-bundles: Build and ship the Java artifact.
  • deploying-go-sdk-bundles: Build, pack, and ship the Go bundle (per-language deploy skills follow the same shape).

© astronomer, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/authoring-language-sdk-tasks of astronomer/agents.

Open the folder on GitHubat commit 486ee63

Compare with similar skills

Authoring Language SDK Tasks next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Authoring Language SDK Tasks compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Authoring Language SDK Tasks this skillastronomer/agents451—~1.8kAutomated safety check: PassApache-2.0
Build Teaql Appteaql/teaql-agent-kit2.8k—~4.6kAutomated safety check: PassMIT
Crap Analyzerswingerman/engineer154—~1.2kAutomated safety check: PassMIT
Geogeometry Maintainerjillesvangurp/geogeometry138—~419Automated safety check: PassCustom licence
Senior Data Engineerbenchflow-ai/skillsbench1.8k—~5.9kAutomated safety check: PassMIT
Airflow DAG Patternswshobson/agents40k9 repos~784Automated safety check: PassMIT

Similar skills

  • Build Teaql App

    teaql/teaql-agent-kit

    Build or change a TeaQL application in Java, Rust, Go, Swift, Python, C/.NET, or TypeScript, including Kotlin/JVM applications that consume Java-generated libraries.

    2.8k GitHub stars~4.6k tokensUpdated 12 days ago
    MobileAuto-check passed
  • Crap Analyzer

    swingerman/engineer

    A skill your agent uses to produce a risk-based refactor + test plan for recently-changed code on a diff/branch/PR by computing CRAP (complexity × untested) on changed methods.

    154 GitHub stars~1.2k tokensUpdated 16 days ago
    Testing & QAAuto-check passed
  • Geogeometry Maintainer

    jillesvangurp/geogeometry

    A skill your agent uses for code, build, and test changes in geogeometry to preserve multiplatform support, geospatial correctness, and strict no-new-dependencies policy.

    138 GitHub stars~419 tokensUpdated 3 mo ago
    Data & AnalyticsAuto-check passed
  • Senior Data Engineer

    benchflow-ai/skillsbench

    World-class data engineering skill for building scalable data pipelines, ETL/ELT systems, real-time streaming, and data infrastructure.

    1.8k GitHub stars~5.9k tokensUpdated 2 mo ago
    Data & AnalyticsAuto-check passed
  • Airflow DAG Patterns

    wshobson/agents

    Patterns for writing production-ready Apache Airflow DAGs: task dependencies, custom operators and sensors, local testing, and rules for what to avoid.

    40k GitHub starsUsed in 9 repos~784 tokens
    Data & AnalyticsAuto-check passed
  • Version Bumper

    godatadriven/whirl

    Bump the Airflow or Python version across all project files.

    205 GitHub stars~1.2k tokensUpdated 8 days ago
    Data & AnalyticsAuto-check passed

More from astronomer/agents

All 34 skills in this repo
  • Analyzing Data

    astronomer/agents

    Queries the data warehouse with SQL and answers business questions about data.

    451 GitHub stars~1.3k tokensUpdated 2 days ago
    Auto-check passed
  • Airflow

    astronomer/agents

    Queries, manages, and troubleshoots Apache Airflow using the af CLI.

    451 GitHub starsUsed in 1 repo~3.8k tokens
    Auto-check passed
  • Guide for migrating Dagster projects to Apache Airflow 3 on Astro.

    451 GitHub stars~3.8k tokensUpdated 2 days ago
    Auto-check passed
  • Authoring Dags

    astronomer/agents

    Workflow and best practices for writing Apache Airflow DAGs.

    451 GitHub starsUsed in 1 repo~1.8k tokens
    Auto-check passed
  • Deploying Airflow

    astronomer/agents

    Deploys Airflow DAGs and projects. An agent skill from astronomer/agents.

    451 GitHub starsUsed in 1 repo~2.8k tokens
    Auto-check passed
  • Airflow Hitl

    astronomer/agents

    Builds human-in-the-loop (HITL) Airflow workflows - approval gates, form input, and human-driven branching.

    451 GitHub stars~1.8k tokensUpdated 2 days ago
    Auto-check passed

Questions about Authoring Language SDK Tasks

What does Authoring Language SDK Tasks do?

The language-neutral foundation for Airflow language SDKs — implement task logic in a non-Python language while the DAG stays in Python. Authoring Language SDK Tasks is an agent skill from astronomer/agents. The language-neutral foundation for Airflow language SDKs — implement task logic in a non-Python language while the DAG stays in Python.

When should I use Authoring Language SDK Tasks?

Authoring Language SDK Tasks fits situations like: the user wants to run an Airflow task in another language (Java; other JVM/native languages); asks how the Python @task.stub pairs with native task code; how task/DAG IDs must match across the two sides.

How do I install Authoring Language SDK Tasks in Claude Code?

Run `npx skills add astronomer/agents --skill authoring-language-sdk-tasks -a claude-code`. Or copy the skill folder (skills/authoring-language-sdk-tasks in astronomer/agents) into .claude/skills/authoring-language-sdk-tasks in your project. Claude Code loads it when a task matches its description.

How do I install Authoring Language SDK Tasks in Codex?

Run `npx skills add astronomer/agents --skill authoring-language-sdk-tasks -a codex`. Or copy the skill folder (skills/authoring-language-sdk-tasks in astronomer/agents) into .agents/skills/authoring-language-sdk-tasks in your project. Codex loads it when a task matches its description.

Can I use Authoring Language SDK Tasks in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add astronomer/agents --skill authoring-language-sdk-tasks -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/authoring-language-sdk-tasks, .gemini/skills/authoring-language-sdk-tasks, .github/skills/authoring-language-sdk-tasks and .opencode/skills/authoring-language-sdk-tasks in your project.

What does Authoring Language SDK Tasks need to run?

SKILL.md names no scripts, command-line tools or credentials: Authoring Language SDK Tasks is instructions for the agent only. Our summary lists: Python 3.

Does Authoring Language SDK Tasks access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Authoring Language SDK Tasks safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Authoring Language SDK Tasks use?

Authoring Language SDK Tasks is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Authoring Language SDK Tasks use?

About 1.8k tokens (SKILL.md is roughly 7.3k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Authoring Language SDK Tasks?

Skills that share tags, products or a category with Authoring Language SDK Tasks: Build Teaql App (teaql/teaql-agent-kit, 2.8k stars), Crap Analyzer (swingerman/engineer, 154 stars), Geogeometry Maintainer (jillesvangurp/geogeometry, 138 stars) and Senior Data Engineer (benchflow-ai/skillsbench, 1.8k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Authoring Language SDK Tasks?

astronomer (a GitHub organization) maintains it in astronomer/agents, which has 451 GitHub stars. The repository holds 34 skills in this directory. The repository was last updated on October 7, 2026.

Source: astronomer/agents on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.