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 definitions, as YAML or OML. 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", "write orchestra oml", "fix validate errors", or when editing `.yml`, `.yaml` or `.oml` 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. Audits the account for earlier or partial attempts first and proposes consolidation. 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, or when auditing, fixing, or consolidating an existing dbt CI setup.

Set up a scheduled Orchestra pipeline that has an agent summarise the workspace's incidents (filtered by status, severity, name and a lookback window) and post them to a Slack channel as a formatted table. Use whenever someone asks to "Setup Scheduled Incident Slack Summary Pipeline", wants a weekly/daily incident digest, report or roundup in Slack, or asks for open incidents to be posted to a channel on a schedule — even if they don't say "pipeline".

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.

Flight assist for tracked flights. Its precheck polls byAir every 2 minutes, sends templated flight notices (delay, gate change, cancellation, boarding, connection risk, inbound delay, time to leave, baggage carousel, day-before check, arrival logistics) through the host itself, and reconciles the managed calendar events. The model is never woken for a notice. Use to configure or diagnose the plugin — 'diagnose flight-assist', 'set flight-assist home base', 'configure flight-assist', 'why didn't I get a flight notice'.

Travel-data refresh bundle: TripIt → Reclaim timezone sync, refresh travel-schedule.json from the TripIt iCal feed with a two-tier Gmail freshness probe, rebuild travel-db.json, log newly-appeared trips to daily memory, then check upcoming trips for booking gaps. Runs daily; precheck-gated on travel-db.json freshness and schema currency. Triggers: 'sync trips', 'sync travel', 'update travel data', 'pull trip info', 'refresh travel schedule', 'rebuild travel db', 'check my bookings'.

Adaptive scheduler for the TripIt/byAir refresh of active-flights.json. Precheck-gated to keep byAir polling responsive on flight days and idle between travel windows. Its precheck sends the sync's notices (tracked-flight changes, sync outage and recovery) through the host itself. Action: diagnose a failed precheck run. Use when active-flights.json isn't updating, byAir polling cadence isn't matching flight density, troubleshooting flight tracking / flight notifications / flight status updates / travel schedule refresh, or setting up flight-assist on a new install. The gate predicate and threshold constants live in skills/sync-tripit/precheck.py.

Shared Python library for trip itineraries, planned positions, conference attendance windows, travel schedules, lodging, airport buffers, trip identity, home addresses and operator timezones in nanoclaw-travel. Flight-assist, drive-engine and travel-booking readers import these modules at runtime. Load when maintaining their shared travel-domain behavior; background library only, never invoke as a user workflow.