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.

Set a redesign direction for an existing website. Analyzes the user's intent, picks a palette and visual direction, and writes the target spec (PRODUCT.md, DESIGN.md, DESIGN.json) plus a reasoning trace at stardust/direction.md. Use when the user asks to redesign a site, refresh the design, set a new design direction, define a redesign target, or invokes /stardust:direct.

Crawl an existing website (capped, multi-page) and seed stardust/current/ with PRODUCT.md, DESIGN.md, DESIGN.json, a per-page inventory, and the consolidated brand surface — the captured design system, palette, typography, motifs, and voice of the live site. Use when the user wants to analyze an existing site's design, extract or reverse-engineer its design system or brand, capture design tokens from a live site, import a website as the starting point for a redesign, capture the current state before a migration, or invokes /stardust:extract. Trigger phrases include "analyze this site", "extract the design tokens", "capture the brand", "crawl the site", "reverse engineer the design". Not for scraping page data or content for its own sake (it captures design evidence, not datasets), and not for the redesign itself — extraction is descriptive; direction and prototyping happen downstream.

Apply DESIGN, canon, and modules to every page in the inventory, producing a deployable static HTML site. Use to migrate or render the whole captured site into the redesigned static tree ("migrate the pages", "render the migrated site", "apply the design to all pages", "build the deployable site", "convert the approved prototype into the full site") — the page-rendering step between prototype and deploy/rollout. Three render branches (approved page, template-applied sibling, unique render), with a declared fidelity tier per page. Per-page, incremental, idempotent, content-preserving by default.

Prepare a whole site for migration by orchestrating the prep cascade — a full-inventory crawl (extract --prep), page-type and module-catalog confirmation (direct --prep), archetype prototypes plus design canon (prototype --prep), and asset preparation — with confirmation gates between phases. Builds the typed page inventory, confirmed module catalog, and canon that stardust:migrate consumes. Use when the user wants to prepare or set up a full-site migration, run migration prep, confirm page types and modules before migrating a site, get a large site ready to migrate, or invokes /stardust:prepare-migration. Trigger phrases include "prepare the migration", "migration prep", "set up the migration data", "get the site ready to migrate". Redesign-flow only — for same-design migrations stardust:replica runs its own preserve-mode prep cascade; never chain prepare-migration with replica. Not for running the migration itself (stardust:migrate) or converting a single page (stardust:deploy).

Render a proposed redesign of a page on the current website as a self-contained static HTML file, then iterate via the impeccable craft loop. Per-page, idempotent, stale-aware. Use when the user asks for a redesign prototype, a before/after comparison, a design preview, a page mockup, a visual diff of the redesign, or invokes /stardust:prototype.

Same-design migration — re-platform a site to AEM Edge Delivery (or any clean front end) keeping its current design near pixel-perfect. Recreates key pages (one archetype per page type) as clean re-authored HTML/CSS (never DOM copies), verifies each against the live site with a measured source-fidelity gate (structural + visual + stitched pixel diff per breakpoint), then hands off to migrate/deploy/rollout for site-wide delivery (subsumes prepare-migration's prep cascade — never chain the two). The only permitted design changes are entries in an explicit inconsistency register. Use when the user says "migrate this site keeping its current design", "same-design migration", "pixel-perfect replatform to AEM", or "keep the design, change the platform". NOT for redesigns — those are the stardust core pipeline (direct/prototype) or uplift.

Rebuild an existing site's pages with byte-faithful content on a separately-defined donor design system — another live site, or local static HTML prototypes (Figma donors are contract-defined, not yet implemented). Content fidelity is gated byte-level (text, ordered images, SEO metadata); design application is flexible (content re-laid-out onto donor modules). Use when the user says "reskin my site with this design", "apply this design system to my content", "restyle my site to look like <other site>", "new design, same content", "rebrand my site using these prototypes", or names a content site plus a design donor. NOT for redesigning from intent (that's the stardust core extract/direct/prototype chain) and NOT for keeping the current design while migrating (that's the replica flow).

Deploy a WHOLE redesigned site to AEM Edge Delivery Services — the full-site, bulk sibling of `deploy` (which ships one page). Use to roll out, bulk-deploy, or publish an entire migrated stardust site at once ("deploy all pages", "full site deployment", "deploy the whole/entire website to AEM"), not just a single page. Inventories the migrated tree (stardust/migrated/ + _meta.json) into a delivery ledger, dedups blocks, drives `deploy` per page, verifies, and tracks what's done and what's left. Supports archetypes-only mode — when only the template archetype pages are migrated, it deploys all block code immediately and registers the rest as content-pending.

Guided multi-page redesign of an existing website through a four-phase pipeline — extract (crawl and capture the current site), direct (set a visual direction), prototype (generate redesigned HTML), and migrate (emit a deployable static site). Tracks progress incrementally per page in stardust/state.json so redesigns are resumable. Delegates the per-page design craft (typography, spacing, color, layout, motion) to the impeccable skill. Use when the user wants to redesign, revamp, modernize, or restyle an existing site they can point to by URL, run the extract/direct/prototype/migrate flow, or resume a multi-page redesign. Also routes the same-design migration flow (replica) and the donor-design flow (reskin). Not for designing a brand-new site from scratch or one-off single-component edits.

One-shot brand-faithful presales redesign of a website page. The user provides only the URL; everything else — extraction, tension identification, three differentiated variants (one fully cinematic), validation — is derived from the captured brand surface. Use when the user asks to "uplift", "refresh", or "redesign a site for presales" without wanting to coordinate the extract / direct / prototype chain themselves.