dagster-cross-job-to-orchestra

Use this skill when a Dagster project creates dependencies between jobs/code locations or triggers downstream runs: @run_status_sensor (on SUCCESS) yielding RunRequest, @asset_sensor watching another job's asset, cross-code-location asset dependencies (SourceAsset / AssetKey across locations), or a sensor that launches another job. Triggers: any sensor/op that launches another Dagster job, any cross-job or cross-code-location asset dependency, any RunRequest targeting a different job.

Quality

71%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/migrate-to-orchestra/skills/dagster-cross-job-to-orchestra/SKILL.md

Quality

Content

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

The body is a strong, highly actionable mapping guide with copy-paste-ready examples for every Dagster pattern it claims to cover. Its main weakness is redundancy — the run-status-sensor mapping and its code are repeated across three sections — and the absence of any verification step for the produced Orchestra configuration.

Suggestions

Collapse the duplication: keep the Before/After example only, or the standalone pattern sections only, and cut the repeated Dagster sensor code and trigger_events YAML; the Gotchas bullets that merely restate section prose ('TRIGGER_PIPELINE always waits', 'pipeline_id is a UUID') can go too.

Add a short verification note (e.g., where to confirm a pipeline's trigger is registered, or how to test a trigger_events pipeline) to close the workflow-clarity checkpoint gap.

Consider moving the TriggerEventModel field table and the TRIGGER_PIPELINE parameter table into a reference file, keeping SKILL.md as the pattern-mapping overview.

Dimension	Reasoning	Score
Conciseness	Mostly efficient — tables and gotchas are compact and load-bearing — but the @run_status_sensor -> trigger_events mapping is shown four times (Overview, its section, the Before/After example, and Gotchas), with the Dagster sensor code and trigger_events YAML each duplicated near-verbatim, and 'TRIGGER_PIPELINE always waits' / 'pipeline_id is a UUID' each stated twice; this could be tightened considerably.	3 / 5
Actionability	Copy-paste-ready YAML for both mechanisms with concrete field values, complete required/optional parameter tables, a full end-to-end before/after example, and specific operational details ('UUID from the Orchestra URL', default statuses 'SUCCEEDED + WARNING', OR logic semantics) covering the common cases.	5 / 5
Workflow Clarity	The central decision — launch-only sensor -> trigger_events:, launch-and-wait -> TRIGGER_PIPELINE — is stated explicitly in both directions with a clear rule for choosing, but there are no validation/verification checkpoints (e.g., how to confirm a trigger is registered or test the resulting YAML), so it falls just short of the fully-checkpointed anchor.	4 / 5
Progressive Disclosure	No bundle files exist, so this is a single-file skill with clear section headers, compact field tables, and a well-signaled References section of external URLs; good structure overall, though Orchestra schema details (TriggerEventModel fields, task parameter reference) could arguably live in a separate reference file, and the under-50-line simple-skill exception does not apply to this ~180-line document.	4 / 5
	Total	16 / 20 Passed

Description

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

The description has excellent trigger-term coverage and distinctiveness, but it omits the 'what': the skill's actual capability (mapping Dagster cross-job patterns to Orchestra trigger_events / TRIGGER_PIPELINE) is never stated, capping completeness at the anchor-2 level despite a rich, explicit 'when' clause.

Suggestions

Lead with a 'what' clause in third person before the trigger guidance, e.g. 'Maps Dagster cross-job patterns (@run_status_sensor, @asset_sensor, cross-code-location dependencies) to their Orchestra equivalents: trigger_events blocks and the TRIGGER_PIPELINE task.'

State the two output mechanisms (trigger_events: and TRIGGER_PIPELINE) explicitly so a reader knows what the skill produces, not just when to invoke it.

Trim the redundant second 'Triggers:' sentence — it largely restates the first sentence's conditions — and spend those tokens on the missing capability statement instead.

Dimension	Reasoning	Score
Specificity	Lists several specific concrete terms — '@run_status_sensor (on SUCCESS) yielding RunRequest', '@asset_sensor watching another job's asset', 'cross-code-location asset dependencies (SourceAsset / AssetKey across locations)' — but never states the skill's own capability (the Orchestra mapping), leaving a minor coverage gap versus the comprehensive anchor 5.	4 / 5
Completeness	The entire description is a 'when' clause ('Use this skill when a Dagster project creates dependencies between jobs... Triggers: any sensor/op that launches...'); what the skill actually does (map these patterns to Orchestra trigger_events / TRIGGER_PIPELINE) is never stated, matching anchor 2's 'only when is present without what' — and per the guidelines I score only what is explicitly stated, so the implied capability from the skill name cannot be credited.	2 / 5
Trigger Term Quality	Comprehensive natural-term coverage with explicit synonyms and variations: '@run_status_sensor', '@asset_sensor', 'RunRequest', 'SourceAsset', 'AssetKey', 'cross-job', 'cross-code-location', 'downstream runs', plus a second 'Triggers:' sentence adding phrasings like 'any sensor/op that launches another Dagster job'.	5 / 5
Distinctiveness Conflict Risk	A clear niche (Dagster cross-job/cross-code-location triggering) with highly distinct API-name triggers, minimal conflict risk with generic or even sibling Dagster-migration skills.	5 / 5
	Total	16 / 20 Passed

Validation

93%

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 — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
referenced_paths_exist	Referenced path issues: 1 missing	Warning

	Total	15 / 16 Passed

Repository: orchestra-hq/orchestra-skills
Path: skills/migrate-to-orchestra/skills/dagster-cross-job-to-orchestra/SKILL.md
Commit: 3a29fe4

Reviewed: 3 days 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.