菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Builds Orchestra pipeline YAML using the native Data Reconciliation tasks (DATA_RECONCILIATION_MANUAL_QUERY, DATA_RECONCILIATION_CURSOR_FIELD) to prove two data stores match — the "did the migration land correctly" check between a source and destination integration (SNOWFLAKE, SQL_SERVER, DATABRICKS, any pairing). Use whenever the user wants to compare, validate, or reconcile data across two systems for a migration, replatform, cutover, or CDC/replication setup — phrases like "make sure the migration matches", "reconcile Snowflake and Databricks", "validate the cutover", "did we lose any rows moving to the new warehouse", "set up drift monitoring", or any mention of Data Reconciliation / DataRec. Produces a one-off full-match validation pipeline plus, optionally, an ongoing cursor-field drift monitor. Don't use create-orchestra-pipeline for this — Data Reconciliation tasks have sharp edges (single-scalar results, thresholds that silently no-op if omitted) covered in this skill's references.
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.
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.
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.
| name | write-snowflake-dq-tests |
| description | 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. |
Goal: inspect real Snowflake data, design tests that fit what each column means (not a generic null check on everything), deploy them as an Orchestra pipeline, run it, and report what's actually wrong. A test that fails because the data is bad is the skill working correctly — do not tune thresholds until everything is green.
Flow: profile → design tests → write pipeline YAML → branch (or create pipeline if no git) → register → run → report.
../../references/orchestra/dq-tests/snowflake.md — Snowflake profiling SQL, the test
catalogue in Snowflake SQL, the pipeline YAML, and Snowflake-specific error causes.../../references/orchestra/dq-tests/workflow.md — the engine-agnostic rest of the workflow:
thresholds, the matrix/gating pattern, branching, registering, triggering, and how to interpret
results. Applies unchanged to Snowflake.snowflake.md §1–2.snowflake.md §3, following the gating pattern and threshold
rules in workflow.md.workflow.md, using the Snowflake-specific error causes and qualified-name
format from snowflake.md §4 when interpreting results.