dagster-sensors-to-orchestra

Use this skill when a Dagster project contains sensors that watch external state and trigger runs: @sensor, @asset_sensor, @multi_asset_sensor, build_sensor_for_freshness_checks, or sensors polling S3/files/tables. Triggers: any @sensor that yields RunRequest based on external state (a file arriving, a row appearing), any @asset_sensor watching upstream materializations, any freshness/observation sensor. Note: @run_status_sensor / @run_failure_sensor are handled by dagster-cross-job-to-orchestra and dagster-alerts-to-orchestra.

Quality

76%

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-sensors-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.

A dense, highly actionable mapping skill: complete enum coverage, concrete copy-paste YAML, and a strong gotchas section that encodes real failure modes. The main costs are token duplication (the S3 example appears twice) and an Overview that re-explains Dagster basics Claude already knows.

Suggestions

Remove the duplicated S3 sensor example — keep it in either the mapping section or the Before/After section, not both, and let the Before/After example use a different sensor type (e.g. the Snowflake SQL one).

Trim the Overview's explanation of what Dagster sensors are; keep only the Orchestra side ('sensors live in the sensors: block at the pipeline root', 'cron window + polling interval with declarative checks') which is the non-obvious knowledge.

Consider moving the full SensorChecksEnum table and the extra mapping examples into a references/ file, keeping SKILL.md to the structure, one worked example, and the gotchas.

Dimension	Reasoning	Score
Conciseness	Mostly efficient, but the S3 @sensor Python block appears nearly verbatim twice (in 'S3-polling @sensor -> AWS_S3_FILE' and again in 'Before / After Example'), and the Overview re-explains what Dagster sensors are ('functions evaluated on a tick interval that inspect external state and yield RunRequest(...)') — concepts Claude already knows. Anchor 3 fits better than 4 given the duplication.	3 / 5
Actionability	Fully executable, copy-paste-ready YAML with real values (cron: '0 6 * * ? *', connection: snowflake_prod_12345, frequency_secs: 60), a complete SensorChecksEnum table, and per-pattern before/after examples covering the common cases (S3 polling, SQL polling, @asset_sensor, trigger_events). Nothing is pseudocode.	5 / 5
Workflow Clarity	Clear per-pattern mapping structure with before/after pairs, and a Gotchas section that flags the real failure modes ('timeout_mins < cron interval', 6-field AWS cron syntax, 'SQL check semantics — passes when the query returns >= 1 row'). Not 5: the process is not sequenced (identify sensor type -> pick SensorChecksEnum value -> map fields -> verify) and there is no checkpoint for validating the generated YAML.	4 / 5
Progressive Disclosure	No bundle files exist (references/, scripts/, assets/ are absent), and all content is inline and well-sectioned (Structure -> enum table -> mapping -> before/after -> gotchas -> references) with clearly signaled external URLs. Good structure overall; not 5 because there is no overview-to-detail split — the enum table and several full mapping examples could live in reference files to keep SKILL.md leaner.	4 / 5
	Total	16 / 20 Passed

Description

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

A highly trigger-oriented description with excellent natural keywords and an explicit boundary against sibling skills. Its one real weakness is that it never states what the skill actually does — the Dagster-to-Orchestra sensor conversion is only implied by the referenced sibling skill names.

Suggestions

State the 'what' explicitly, e.g. 'Converts Dagster sensors (@sensor, @asset_sensor, @multi_asset_sensor, build_sensor_for_freshness_checks) to Orchestra sensors-block YAML with declarative SensorChecksEnum checks.'

Mention 'Orchestra' in the trigger clause itself, not just via sibling skill names, so the description is self-contained about the target format.

Optionally add common natural variations users might say, such as 'file arrival sensor' or 'data readiness check', to broaden trigger coverage.

Dimension	Reasoning	Score
Specificity	Names the domain plus concrete identifiers ('@sensor, @asset_sensor, @multi_asset_sensor, build_sensor_for_freshness_checks, or sensors polling S3/files/tables'), but these are trigger indicators rather than the skill's actions — what the skill actually does is never stated. Fits anchor 4 (several specifics, minor gaps) rather than 5 (comprehensive concrete actions).	4 / 5
Completeness	'When' is explicit and thorough ('Use this skill when a Dagster project contains sensors that watch external state and trigger runs' plus a 'Triggers:' list), but 'what' the skill does is absent — the transformation to Orchestra is only implied by sibling skill names, and per the guidelines we do not infer it. Falls between anchors 3 and 4; the missing explicit 'what' holds it at 3.	3 / 5
Trigger Term Quality	Comprehensive natural terms: decorator names ('@sensor', '@asset_sensor', '@multi_asset_sensor'), 'freshness/observation sensor', 'sensors polling S3/files/tables', 'upstream materializations', and 'RunRequest' — exactly the phrases a Dagster user would say. Not below 5 since no common variation or synonym is missing.	5 / 5
Distinctiveness Conflict Risk	Clear niche with an explicit exclusion boundary: '@run_status_sensor / @run_failure_sensor are handled by dagster-cross-job-to-orchestra and dagster-alerts-to-orchestra'. Highly specific Dagster decorators make triggering for the wrong skill very unlikely.	5 / 5
	Total	17 / 20 Passed

Validation

100%

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

Validation for skill structure

No warnings or errors.

Repository: orchestra-hq/orchestra-skills
Path: skills/migrate-to-orchestra/skills/dagster-sensors-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.