creating-openlineage-extractors

Create custom OpenLineage extractors for Airflow operators. Use when the user needs lineage from unsupported or third-party operators, wants column-level lineage, or needs complex extraction logic beyond what inlets/outlets provide.

1.29x

Quality

71%

Does it follow best practices?

Impact

97%

1.29x

Average score across 3 eval scenarios

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/creating-openlineage-extractors/SKILL.md

Quality

Content

65%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 highly actionable, code-dense skill that covers both extraction approaches with executable examples, registration, pitfalls, and tests. Its weaknesses are the absence of an explicit step-by-step workflow with a registration-verification checkpoint and the monolithic single-file layout that inlines pattern and testing material a references/ directory could hold.

Suggestions

Add an explicit numbered workflow (choose approach via the decision table -> implement -> register -> verify registration -> test) including a validation step that confirms Airflow actually loaded the extractor, e.g. checking the OpenLineage events emitted for a test DAG run.

Move the 'Common Patterns' SQL/file-transfer/dynamic extractor examples and the 'Testing Extractors' section into a references/ file (e.g. references/patterns.md), keeping SKILL.md as a lean overview with one-level-deep pointers.

Trim the redundant 'Two Approaches' section (it restates the decision table) and consolidate the repeated import boilerplate across code snippets to reduce token cost.

Dimension	Reasoning	Score
Conciseness	The body is code-first and avoids explaining concepts Claude already knows, but has minor trimmable redundancy: the 'Two Approaches' section restates the decision table, and each code snippet repeats import boilerplate.	4 / 5
Actionability	Nearly all guidance is concrete and executable (operator methods, extractor classes, registration config, wrong/right pitfall examples, a runnable unit test), with minor gaps such as the acknowledged _parse_sql stub and namespace="..." placeholders in the dynamic example.	4 / 5
Workflow Clarity	The decision table and testing section provide implicit checkpoints and sections are logically ordered, but the process is never enumerated as an explicit step sequence and there is no validation step confirming the extractor was actually registered and picked up by Airflow.	3 / 5
Progressive Disclosure	The single ~400-line SKILL.md is well-sectioned with clear headers, but no bundle files exist and roughly 150 lines of common-pattern and testing content would be better placed in one-level-deep reference files, matching 'content that should be separate is inline'.	3 / 5
	Total	14 / 20 Passed

Description

78%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.

A strong description with an explicit what-and-when structure and concrete trigger conditions that also delineate the skill from the simpler inlets/outlets approach. Its only weakness is that it names a single capability rather than enumerating the fuller range of what the skill covers (operator methods, registration, testing).

Dimension	Reasoning	Score
Specificity	The description names the domain (Airflow OpenLineage) and one concrete action ('Create custom OpenLineage extractors for Airflow operators') but lists no further capabilities such as implementing operator methods, registering extractors, or testing them, matching the anchor for 1-2 concrete actions that are not comprehensive.	3 / 5
Completeness	It explicitly answers both 'what' ('Create custom OpenLineage extractors for Airflow operators') and 'when' ('Use when the user needs lineage from unsupported or third-party operators, wants column-level lineage, or needs complex extraction logic beyond what inlets/outlets provide') with three concrete trigger conditions.	5 / 5
Trigger Term Quality	Good natural-term coverage: 'lineage', 'unsupported or third-party operators', 'column-level lineage', and 'inlets/outlets' are phrases users would plausibly say, though common variations like 'data lineage', 'track lineage', or 'custom operator' are absent.	4 / 5
Distinctiveness Conflict Risk	The custom-extractor niche is distinct and the explicit contrast with inlets/outlets delineates it from the sibling annotating-task-lineage skill, but it still overlaps mildly with other lineage-related skills, fitting 'mostly distinct; minor overlap risk'.	4 / 5
	Total	16 / 20 Passed

Validation

100%

Warnings & errors only

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: astronomer/agents
Path: skills/creating-openlineage-extractors/SKILL.md
Commit: 1ec1a1f

Reviewed: 1 day ago

Table of Contents

Discovery Implementation Validation

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.