Content
86%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
A well-executed shared-foundation skill: a runnable stub example, precise rules with enforcement details (AST check, ValueError on retry_policy), a clean JSON contract table, and rigorous delegation of language-specific content to named sibling skills. The only flaws are minor: the queue-to-coordinator rule is repeated three times and there are no explicit pre-deploy validation checkpoints.
Suggestions
State the queue_to_coordinator requirement once (e.g., in the rules list) and drop the duplicate mention in the prose above the example and the inline code comment.
Add a short pre-deploy validation step in the pitfalls section, e.g. 'before deploying, confirm the native task/DAG IDs exactly match the stub function and @dag names — mismatches only surface at runtime as "no DAGs" or missing-XCom errors'.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is lean and assumes competence — no space is spent on what Airflow, JSON, or subprocesses generically are; sections like 'The model' deliver dense, skill-specific facts. However, the queue-routing point ('the same string must appear in queue_to_coordinator') is made three times (prose at the top of the Python-side section, the code comment, and the rules bullet), which is trimmable repetition. Not 5: the anchor-5 example has zero redundancy; not 3: the rest is efficient with only these minor over-explanations. | 4 / 5 |
Actionability | The Python stub example is complete and copy-paste ready (imports, decorators, dependency wiring, an ordinary downstream task), and the pitfalls section gives executable specifics: 'only pass, ..., or a docstring is allowed in the body', '@task.stub raises ValueError' for retry_policy, and mismatch symptoms ('no DAGs' or missing-XCom errors). The native half is deliberately delegated to named per-language skills, which is an explicit, justified scope split rather than a gap. Not 4: there is no missing detail within the skill's declared scope. | 5 / 5 |
Workflow Clarity | This is a conceptual/shared-foundation skill rather than a multi-step procedure, and its explanatory sequence is coherent (model → two-sided pattern → data contract → what lives elsewhere → pitfalls), with error-symptom feedback ('mismatches surface as "no DAGs" or missing-XCom errors'). Not 5: there is no explicit validation checkpoint (e.g., 'verify stub and native IDs match before deploying') or validate-then-proceed loop, which the anchor-5 example requires. Not 3: the failure modes and their symptoms are stated, so validation guidance is more than implicit. | 4 / 5 |
Progressive Disclosure | No bundle files exist (no references/, scripts/, or assets/), and none are needed: the body stays at overview level and pushes per-language detail to clearly named one-level-deep sibling skills ('authoring-java-sdk-tasks', 'authoring-go-sdk-tasks', 'configuring-airflow-language-sdks', deploy skills), each listed with a one-line scope summary under 'Per-language skills' and 'Related Skills'. Navigation is easy and the split is exactly along the shared/language-specific boundary. Not 4: every out-of-scope topic has a clearly signaled destination, with no buried references or inlined content that belongs elsewhere. | 5 / 5 |
Total | 18 / 20 Passed |