authoring-dags
Workflow and best practices for writing Apache Airflow DAGs. Use when the user wants to create a new DAG, write pipeline code, or asks about DAG patterns and conventions. For testing and debugging DAGs, see the testing-dags skill.
68
83%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Quality
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 clear 'Use when' clause, good trigger terms, and an explicit scope boundary distinguishing it from the testing-dags skill. The main weakness is that the 'what' portion could be more specific about the concrete actions it covers (e.g., defining operators, setting schedules, configuring task dependencies) rather than the somewhat general 'workflow and best practices.'
Suggestions
Add more specific concrete actions to the 'what' portion, e.g., 'Covers defining operators, setting schedules, configuring task dependencies, and structuring DAG files.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Apache Airflow DAGs) and mentions some actions ('create a new DAG', 'write pipeline code', 'DAG patterns and conventions'), but doesn't list specific concrete actions like defining operators, setting schedules, configuring dependencies, or handling retries. | 2 / 3 |
Completeness | Clearly answers both 'what' (workflow and best practices for writing Airflow DAGs) and 'when' (explicit 'Use when' clause covering creating DAGs, writing pipeline code, or asking about patterns). Also helpfully delineates scope by pointing to a separate testing skill. | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'Airflow', 'DAG', 'DAGs', 'pipeline code', 'DAG patterns', 'conventions', 'create a new DAG'. These cover the most common ways users would phrase requests about writing Airflow DAGs. | 3 / 3 |
Distinctiveness Conflict Risk | Clearly scoped to Apache Airflow DAG authoring with distinct triggers. The explicit boundary ('For testing and debugging DAGs, see the testing-dags skill') further reduces conflict risk by disambiguating from a related skill. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured workflow skill with strong actionability and clear validation checkpoints. Its main weaknesses are moderate redundancy (duplicate tables, repeated testing-dags references, bulky ASCII diagram) and reliance on bundle files (reference/best-practices.md) that aren't provided, leaving Phase 3 (Implement) essentially hollow. The workflow clarity is excellent with proper feedback loops and user consent gates.
Suggestions
Remove the duplicate CLI commands between the discovery table in Phase 1 and the CLI Quick Reference table, or consolidate into a single reference section.
Replace the ASCII box diagram with a compact numbered list — the same information is conveyed in the phase headings already.
Include at minimum a brief inline summary of key best practices in Phase 3 so the skill is useful even without the bundle file reference/best-practices.md.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Generally efficient but has some redundancy — the ASCII workflow diagram is bulky for what could be a numbered list, and several phases repeat information (e.g., Phase 5 and Phase 6 both reference the testing-dags skill multiple times). The discovery table and CLI quick reference table also overlap significantly. | 2 / 3 |
Actionability | Provides specific, executable CLI commands for every phase (af dags errors, af dags get, af dags explore, af runs trigger-wait), with clear tables mapping commands to purposes. The validation steps are concrete and copy-paste ready. | 3 / 3 |
Workflow Clarity | The six-phase workflow is clearly sequenced with explicit validation checkpoints in Phase 4 (check errors → verify DAG exists → check warnings → explore structure), a feedback loop in Phase 6 (fix → re-validate → re-test), and conditional branching ('If your file appears -> fix and retry'). The destructive operation (triggering runs) requires explicit user consent. | 3 / 3 |
Progressive Disclosure | Good cross-references to testing-dags skill and reference/best-practices.md, but the bundle has no files to support these references. The best-practices reference is critical for Phase 3 (Implement) yet the phase itself is nearly empty, making the skill dependent on a file that doesn't exist in the bundle. The related skills section is well-organized but some inline content (like the CLI quick reference duplicating the discovery table) could be better structured. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
- 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.