Configure dbt source freshness for Orchestra state-aware orchestration — author warn_after/error_after thresholds and loaded_at_field/loaded_at_query in a dbt project's sources YAML, getting the warehouse details right for Snowflake, BigQuery, Databricks, or MotherDuck/DuckDB, then enable use_state_orchestration on the Orchestra dbt task. Use when asked to set up dbt source freshness, configure freshness checks, detect stale sources, set up state-aware orchestration in Orchestra, or make Orchestra skip downstream models when upstream data hasn't changed. Trigger on phrases like "add source freshness", "configure freshness", "set up state aware orchestration", "skip models when sources are stale", "loaded_at_field", or "warn_after/error_after" in a dbt or Orchestra context. This is the source/freshness-signal half of state-aware orchestration; configuring per-model rebuild SLAs (build_after) is the separate configure-dbt-build-after skill.

Create, validate, and remediate Orchestra pipeline YAML files. Use when asked to build a new pipeline, add tasks to an existing pipeline, fix pipeline validation errors, or author Orchestra workflow definitions from a description. Trigger on phrases like "create a pipeline", "add a dbt task", "write orchestra yaml", "fix validate errors", or when editing files under orchestra/ or similar pipeline directories.

Fix a failed Orchestra pipeline once the failure has been identified as an Orchestra-platform / configuration issue — pipeline YAML misconfiguration, wrong or missing task inputs, task ordering, env/connection wiring, a transient Orchestra-side blip needing a plain retry, or an Orchestra-backed pipeline that needs update_pipeline. Also the fallback fixer for repo-level code fixes in integrations that don't have a dedicated skill (e.g. a Snowflake/HTTP SQL bug needing a PR). Normally invoked by identify-pipeline-error after it classifies the cause; for dbt-code or Python-code failures, that router calls fix-pipeline-dbt-task or fix-pipeline-python-task instead. This skill is the FIX half (apply fix → PR/poll → retry → confirm → optionally remember); identification and classification live in identify-pipeline-error.

Fix a dbt Core task in an Orchestra Pipeline once the failure has been identified as a dbt code/config issue. Normally invoked by identify-pipeline-error after it classifies the cause; it can also run standalone if the user points directly at a broken dbt task. Succinct, API-first workflow refined from real fixes. Identification/classification lives in identify-pipeline-error — this skill is the FIX half: reproduce → fix → validate on a branch → confirm → merge.

Fix a Python task in an Orchestra Pipeline once the failure has been identified as a Python code / dependency / destination-schema issue. Normally invoked by identify-pipeline-error after it classifies the cause; it can also run standalone if the user points directly at a broken Python task. Succinct, API-first. Biased toward editing the script and re-running until it works, with additive-only schema changes to the destination. Identification/classification lives in identify-pipeline-error — this skill is the FIX half.

The entry point for fixing anything in an Orchestra pipeline. Use this skill FIRST whenever a user wants to fix, debug, retry, or understand a failed Orchestra pipeline — e.g. "fix my pipeline", "what's broken", "why did my pipeline fail", "debug this run", "retry it" — or pastes an Orchestra run URL, a UUID, a pipeline name/alias, an error message, or a Slack/alert message. This skill does NOT fix anything itself beyond a few categories. It GETs the pipeline run and the task runs, identifies which task failed, its integration, and the cause, then HANDS OFF to the right fixer: a Python task code issue → fix-pipeline-python-task; a dbt task code/config issue → fix-pipeline-dbt-task; an Orchestra-platform/configuration issue → fix-orchestra-pipeline. All other causes (data quality, vendor/ingestion, auth, network, timeout/infra, upstream, and other integrations) are handled here.

Finds Orchestra pipelines that are really the same process duplicated — across environments (`_prod`/`_staging`/`_dev`/`-uat` naming, or Orchestra's native Environments) or conceptually (same task graph copy-pasted per customer/region/business-unit under unrelated names) — then drafts one consolidated pipeline using Environment overlays, `${{ ENV.* }}`, inputs, conditionals, or a MetaEngine matrix instead of the duplication. Use when the user wants to "consolidate", "merge", "dedupe", or "unify" pipelines, asks "why do I have three copies of this pipeline", or wants to act on an account-health-check finding about one-pipeline-per-environment, duplicated tasks, or hardcoded environment values. Also trigger when handed an existing account-review report flagging those. Always shows evidence and a drafted YAML before touching anything, and asks per duplicate set whether to report, create/PR the unified pipeline, or also pause the originals — never merges, deletes, or pauses without that go-ahead.

Retrofits dbt Slim CI onto an existing Orchestra production dbt pipeline using latest_production, state:modified+, and --defer, with GitHub Actions run-pipeline as the primary CI trigger. Use when setting up Orchestra Slim CI, dbt CI/CD in Orchestra, run-pipeline for dbt, or latest_production defer state in a dbt repo or from outside it.

Diagnose a failed Orchestra pipeline, open a fix PR, validate it on a branch run, then present a human-readable triage summary and STOP for user approval before merging. Use this when the user wants to review the fix before it goes to main — not for fully automated fixes. Trigger on phrases like "triage my pipeline", "show me what's broken", "investigate but don't fix yet", "prepare a fix for review", or when the user explicitly wants a review gate before applying changes. Also trigger when the user describes a symptom in a downstream system ("dashboard looks wrong", "chart is stale", "dbt model has bad data") even if no pipeline error exists — the skill will trace the symptom upstream.

Profile BigQuery data, design data-quality tests appropriate to what each column actually is, then build and deploy a BigQuery DQ testing pipeline to Orchestra.

Profile ClickHouse data, design data-quality tests appropriate to what each column actually is, then build and deploy a ClickHouse DQ testing pipeline to Orchestra.

Profile Databricks data, design data-quality tests appropriate to what each column actually is, then build and deploy a Databricks DQ testing pipeline to Orchestra.

Profile Snowflake data, design data-quality tests appropriate to what each column actually is, then build and deploy a Snowflake DQ testing pipeline to Orchestra.