tracing-upstream-lineage
Trace upstream data lineage. Use when the user asks where data comes from, what feeds a table, upstream dependencies, data sources, or needs to understand data origins.
60
70%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/tracing-upstream-lineage/SKILL.mdQuality
Discovery
89%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a well-structured skill description with a strong 'Use when' clause containing excellent natural trigger terms. Its main weakness is that the 'what' portion is somewhat thin—it only states 'trace upstream data lineage' without elaborating on specific actions or outputs. Despite this, the description is highly functional for skill selection due to its rich trigger coverage and clear niche.
Suggestions
Expand the 'what' portion with additional concrete actions, e.g., 'Trace upstream data lineage by identifying source tables, mapping transformation steps, and documenting dependency chains.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (data lineage) and a core action ('trace upstream data lineage'), but it only describes one action rather than listing multiple specific concrete actions like identifying source tables, mapping transformation steps, or visualizing dependency graphs. | 2 / 3 |
Completeness | Clearly answers both 'what' (trace upstream data lineage) and 'when' (explicit 'Use when' clause listing multiple trigger scenarios like asking about data sources, upstream dependencies, and data origins). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural terms users would say: 'where data comes from', 'what feeds a table', 'upstream dependencies', 'data sources', 'data origins'. These are all phrases a user would naturally use when needing this skill. | 3 / 3 |
Distinctiveness Conflict Risk | The focus on 'upstream data lineage' is a clear niche with distinct triggers. Terms like 'upstream dependencies', 'what feeds a table', and 'data origins' are specific enough to avoid conflicts with general data analysis or ETL skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
50%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides a solid methodological framework for tracing upstream data lineage in Airflow environments, with clear step-by-step structure and useful CLI commands. Its main weaknesses are the lack of validation/error-handling checkpoints in the workflow, somewhat verbose output template section, and guidance that leans more toward methodology than fully executable instructions. The cross-references to related skills are a strength for navigation.
Suggestions
Add explicit validation checkpoints and error-handling guidance, e.g., 'If no DAG matches the table name, search DAG source code with grep for the table name across all DAG files'
Trim the output template section — the lineage report format could be condensed or moved to a separate TEMPLATE.md file to reduce the main skill's length
Make the CLI examples more concrete and copy-paste ready, e.g., show exact grep/search commands for finding table references in DAG source code rather than just describing what to look for
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is reasonably efficient but includes some unnecessary explanation (e.g., listing obvious file source types like 'CSV/Parquet files in object storage', 'SFTP drops', 'Local file paths'). The output template section is quite lengthy and could be trimmed. However, most content is instructive rather than explanatory. | 2 / 3 |
Actionability | Provides concrete CLI commands (`af dags list`, `af dags source <dag_id>`, `af tasks list <dag_id>`) and SQL pattern examples, but the guidance is more of a methodology/checklist than fully executable steps. The code examples are illustrative fragments rather than copy-paste ready commands, and the lineage diagram is a template rather than executable output. | 2 / 3 |
Workflow Clarity | The 5-step sequence is clearly laid out and logically ordered, with a recursive tracing step (Step 4). However, there are no explicit validation checkpoints or feedback loops — for instance, no guidance on what to do if a DAG can't be found for a table, or if source code doesn't reveal the expected patterns. The 'Check Source Health' step is present but lacks verification criteria. | 2 / 3 |
Progressive Disclosure | The skill references several related skills at the end (checking-freshness, debugging-dags, etc.) which is good navigation. However, with no bundle files, these references are unverifiable. The content itself is somewhat long (~100 lines of substantive content) and the output template section could potentially be split into a separate reference file. The structure within the file is well-organized with clear headers. | 2 / 3 |
Total | 8 / 12 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 — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- astronomer/agents
- Commit
535a040
- 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.