Content
82%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 strong, highly actionable reference: complete executable YAML/Python for both setting and consuming outputs, a thorough pattern-mapping table, and a gotchas section packed with genuinely non-obvious failure modes (silent set_output ignoring, triple-quote JSON escaping, hyphenated task IDs). The main weaknesses are mild over-explanation of Dagster basics in the overview and the absence of any verify-the-output checkpoint in the workflow.
Suggestions
Trim the opening Dagster recap ('an op returns a value, an IO manager persists it... This is one of Dagster's core abstractions') down to the single contrast sentence, since Claude already knows how Dagster IO works.
Add a one-line verification checkpoint, e.g. after setting outputs, confirm the key appears in the task run's outputs before wiring downstream references — this closes the workflow-clarity validation gap.
Move the 'set_outputs: true — Supported Integrations' table into a references/ file (e.g. references/supported-integrations.md) to keep SKILL.md a leaner overview, since the table is lookup material rather than core guidance.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense and almost every token earns its place: the pattern-mapping table, the gotchas list, and the triple-quote JSON rule are non-obvious, novel information. However, the overview opens with a recap of concepts Claude already knows — 'an op returns a value, an IO manager persists it, and the downstream op receives it as a typed input. This is one of Dagster's core abstractions' — which is over-explanation that could be trimmed. Not a 5 because of that padding; not a 3 because the verbosity is minor and isolated. | 4 / 5 |
Actionability | Quotes: complete copy-paste-ready YAML ('parameters: command: python scripts/get_row_count.py ... set_outputs: true'), complete Python ('client = OrchestraSDK(api_key=os.environ.get("ORCHESTRA_API_KEY")) ... client.set_output("pending_count", count)'), the exact downstream reference syntax ('${{ ORCHESTRA.PIPELINE_RUN_TASKS['get-row-count'].OUTPUTS['pending_count'] }}'), and a full before/after example covering the common cases (SQL auto-capture, condition branching). The few ellipses ('connect(...)') are clearly deliberate placeholders, not pseudocode. Not a 4 because the common cases are fully executable end-to-end. | 5 / 5 |
Workflow Clarity | The content flows in a clear, logical sequence: architectural difference -> pattern mapping table -> setting outputs -> referencing outputs downstream -> supported integrations -> full worked example -> gotchas, so the migration path is unambiguous in both directions. Not a 5 because there are no explicit validation checkpoints (e.g. 'verify the output appears in the run before wiring downstream references') and no numbered feedback loop; the rubric's destructive/batch cap does not apply since this is mapping guidance, not a batch operation skill. Not a 3 because the sequence is clear and checkpoints are not required for the risk profile of this skill. | 4 / 5 |
Progressive Disclosure | No bundle files exist, so everything is inline; the body is well-sectioned with clear headers (Overview, Pattern Mapping, Setting Outputs, Referencing Outputs, Supported Integrations, Before/After, Gotchas, References) and the References section points to clearly labeled external docs one level deep. At ~195 lines, content such as the 'set_outputs: true — Supported Integrations' table and part of the gotchas list could arguably live in a reference file to keep SKILL.md a leaner overview, which keeps this at anchor 4 ('minor organization gaps') rather than 5. | 4 / 5 |
Total | 17 / 20 Passed |