CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

airflow-java-sdk

Guide for contributing to the Airflow Java SDK (AIP-108). Use this skill whenever a contributor is working in the `java-sdk/` directory or on the Java coordinator in `task-sdk/src/airflow/sdk/coordinators/java/` — whether they want to add a feature, write tests, fix a bug, understand the architecture, or prepare a PR. Trigger on phrases like "Java SDK", "JavaCoordinator", "java-sdk", "annotation processor", "Airflow.Task", "BundleBuilder", or anything about running JVM tasks in Airflow.

Quality

93%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

82%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A strong, highly actionable contributor guide: exact Breeze/Gradle/E2E commands, a precise file map, and correct emphasis on reading the authoritative repo docs early. Its weaknesses are modest — some trimmable architectural detail in the manifest-discovery section, implicit rather than explicit validation checkpoints, and a 'Read these two documents' intro that actually lists three documents.

Suggestions

Trim the fat-JAR/thin-JAR manifest mechanics and the internal-package class enumeration (e.g. `CoordinatorComm`, `LogSender`, `Log`) from SKILL.md, leaving a one-line summary and pointing to `java-sdk/DEVELOPMENT.md` for the detail.

Add explicit validation checkpoints to the workflows: after the schema-upgrade steps, note to verify the Gradle build and coordinator tests pass before proceeding, mirroring the build-time Main-Class validation the guide already mentions.

Fix the intro inconsistency — 'Read these two documents early in every session' is followed by three documents (`java.rst`, `README.md`, `DEVELOPMENT.md`) — and clarify which are essential versus optional.

DimensionReasoningScore

Conciseness

The body is information-dense and project-specific rather than padded, but minor over-explanation could be trimmed: the exhaustive internal-class enumeration ("`CoordinatorComm`, `LogSender`, `Log`, `Client` in `execution/`, generated schema models, etc.") and the fat/thin-JAR manifest mechanics ("In fat-JAR mode (the default), the Gradle plugin reads this value from the `airflow-sdk` JAR in `runtimeClasspath`...") are detail that belongs in DEVELOPMENT.md. This sits at 'efficient with minor trimmable instances', not level 3, since virtually all content is non-obvious project knowledge Claude cannot already know.

4 / 5

Actionability

Guidance is copy-paste ready: exact test commands (`breeze testing task-sdk-tests -- task_sdk/coordinators/java`, `E2E_TEST_MODE=java_sdk uv run --project airflow-e2e-tests pytest tests/airflow_e2e_tests/java_sdk_tests/ -xvs`), a concrete Gradle task (`./gradlew generateJsonSchema2Pojo`), the exact method a subclass must implement ("`_build_execute_task_command`, which returns `(argv, schema_version)`"), and a key-files table mapping each file to its purpose. The common cases (test, extend coordinator, upgrade schema) are all covered executably, matching the top anchor; the single vaguer step ("Modify `execution/Client.kt` to handle changes") is explicitly delegated to the step-by-step walkthrough in DEVELOPMENT.md.

5 / 5

Workflow Clarity

Per-task sequences are present and concrete — testing commands, the schema-upgrade steps ("Regenerate models with `./gradlew generateJsonSchema2Pojo`" then "Modify `execution/Client.kt`"), and the read-docs-first instruction — but validation checkpoints are implicit rather than explicit (e.g., nothing says to confirm the Gradle build/validation passes after changes, though the build-time class-signature validation is mentioned in passing). This lands at 'clear sequence with most checkpoints present; minor validation gaps' rather than 5; it does not drop to 3 since this is a contributor guide, not a destructive or batch operation, and tests themselves serve as the feedback loop.

4 / 5

Progressive Disclosure

Structure is good: clear section headers, a key-files table, and well-signaled one-level-deep references with content summaries ("`java-sdk/DEVELOPMENT.md` — contributor guide: repository layout, detailed execution walkthrough, Gradle + Breeze test commands..."). The ~30-line bundle-composition/manifest-discovery section is inline detail that could arguably live in a separate reference file, which keeps this at 'good structure, most content appropriately placed, minor organization gaps' rather than the fully-split top anchor; it is above level 3 because the references that do exist are clearly signaled, not buried.

4 / 5

Total

17

/

20

Passed

Description

100%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

An exemplary description: third-person voice, explicit what and when clauses, enumerated concrete contributor activities, and a rich list of trigger phrases including paths and class names. It fully satisfies every dimension's top anchor with no padding or over-claims.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions — "add a feature, write tests, fix a bug, understand the architecture, or prepare a PR" — anchored to a specific domain ("contributing to the Airflow Java SDK (AIP-108)"). This matches the top anchor of several specific concrete actions with comprehensive coverage; it does not fall to 4 because no meaningful contributor activity is left uncovered.

5 / 5

Completeness

Both questions are answered explicitly: what ("Guide for contributing to the Airflow Java SDK (AIP-108)... whether they want to add a feature, write tests, fix a bug...") and when ("Use this skill whenever a contributor is working in the `java-sdk/` directory or on the Java coordinator in `task-sdk/...`") followed by concrete "Trigger on phrases like...". This mirrors the 5 anchor's what+when-with-concrete-trigger-phrases pattern; the 4 anchor's weaker/'could be more explicit' when-clause does not apply.

5 / 5

Trigger Term Quality

Trigger phrases are enumerated explicitly: "Java SDK", "JavaCoordinator", "java-sdk", "annotation processor", "Airflow.Task", "BundleBuilder", plus directory/path forms (`java-sdk/`, `task-sdk/src/airflow/sdk/coordinators/java/`) and the natural catch-all "anything about running JVM tasks in Airflow". Coverage includes case variants, class names, and paths, matching the comprehensive-synonyms anchor rather than the 'a few natural terms missing' level 4.

5 / 5

Distinctiveness Conflict Risk

The niche is tightly scoped with unique identifiers ("Airflow Java SDK (AIP-108)", "JavaCoordinator", "BundleBuilder", exact repo paths), so it would not fire for unrelated skills. This is a clear-niche-with-distinct-triggers case; level 4's 'minor overlap risk with closely related skills' is not present since no other plausible skill shares these triggers.

5 / 5

Total

20

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

apache/airflow

Path

.agents/skills/airflow-java-sdk/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.