---
name: dbt-projects-on-snowflake
description: "ONLY for dbt projects deployed INTO Snowflake as native objects via the `snow dbt` CLI — NOT for normal dbt development. Invoke ONLY when the user explicitly mentions: `snow dbt` commands (deploy, execute, list), `EXECUTE DBT PROJECT` SQL, a deployed dbt project object (e.g., DB.SCHEMA.MY_PROJECT), `ALTER/DROP/DESCRIBE/SHOW DBT PROJECT` SQL, scheduling a deployed dbt project with CREATE TASK, OR generating documentation/catalog/lineage for a deployed project. Do NOT invoke for standard dbt workflows: dbt run, dbt build, dbt test, dbt seed, dbt init, dbt compile, dbt debug, dbt snapshot, dbt deps, dbt clean, dbt retry, dbt ls, profiles.yml, dbt_project.yml, model editing, source freshness, Jinja/macro development, CI/CD pipelines, or any dbt command run from a terminal. The key distinction: this skill is about dbt-as-a-Snowflake-object (snow dbt deploy), not dbt-as-a-CLI-tool (dbt run). Triggers: snow dbt, snow dbt deploy, snow dbt execute, snow dbt list, EXECUTE DBT PROJECT, deployed dbt project, ALTER DBT PROJECT, DROP DBT PROJECT, DESCRIBE DBT PROJECT, SHOW DBT PROJECTS, VERSION$, external-access-integration, dbt project object, migrate, prepare for snowflake, docs generate deployed, documentation deployed project, data catalog deployed, lineage deployed project, generate documentation for deployed."
---

# Snowflake-Native dbt Projects

Deploy and run dbt Core projects directly **inside Snowflake** using the `snow` CLI and `EXECUTE DBT PROJECT` SQL.

**SCOPE:** This skill covers dbt projects deployed as Snowflake objects — created via `snow dbt deploy`, executed via `snow dbt execute` or `EXECUTE DBT PROJECT` SQL, and managed via `ALTER/DESCRIBE/DROP/SHOW DBT PROJECT` SQL.

**DO NOT use this skill when:**
- The user is running dbt locally against Snowflake (standard `dbt run`, `dbt build`, `dbt test`, `dbt seed`)
- The user is editing dbt models, fixing SQL bugs, writing macros, or doing dbt development work
- The user has a local `profiles.yml` with password/authenticator fields (this is normal for local dbt)
- The user is configuring `dbt_project.yml`, `packages.yml`, or project structure
- The user mentions `dbt init`, `dbt debug`, `dbt deps`, `dbt clean`, `dbt compile`, `dbt snapshot`, `dbt retry`, `dbt ls`
- The user asks about CI/CD, GitHub Actions, source freshness, or dbt documentation
- There is NO mention of `snow dbt`, a deployed project, a project in a Snowflake schema, or `EXECUTE DBT PROJECT`

If the user's request matches the above, do NOT load any sub-skills — just answer using standard dbt knowledge.

**WHY THIS SKILL EXISTS:** Snowflake's native dbt integration uses unique syntax (`snow dbt`, `EXECUTE DBT PROJECT`) that differs from standard dbt CLI. This skill provides the correct syntax for that specific workflow.

---

## Intent Detection

**Only match these intents when the user is explicitly working with Snowflake-native dbt (deployed projects, `snow dbt`, `EXECUTE DBT PROJECT`).** Do NOT match for standard local dbt CLI work.

| Intent | Triggers | Action |
|--------|----------|--------|
| **DEPLOY** | "snow dbt deploy", "deploy dbt project to snowflake", "create dbt project in snowflake", "upload dbt", "external access integration" | Load `deploy/SKILL.md` |
| **EXECUTE** | "snow dbt execute", "EXECUTE DBT PROJECT", "run deployed project", "execute deployed project", "snow dbt show", "run the deployed", "run in deployed", "execute in deployed", "docs generate", "generate documentation", "documentation", "data catalog", "catalog", "lineage" | **⚠️ You MUST read `execute/SKILL.md`** - it has CRITICAL syntax for docs generate |
| **MANAGE** | "snow dbt list", "list dbt projects", "show dbt projects", "describe dbt project", "drop dbt project", "rename dbt project", "SHOW DBT PROJECTS", "ALTER DBT PROJECT", "add version", "VERSION$", "set comment", "set default target" | Load `manage/SKILL.md` |
| **SCHEDULE** | "schedule dbt project", "CREATE TASK for dbt", "EXECUTE DBT PROJECT in task", "automate dbt runs", "Snowflake task for dbt" | Load `schedule/SKILL.md` |
| **MONITOR** | "dbt execution logs", "dbt artifacts", "dbt archive", "dbt execution history", "download artifacts" | Load `monitoring/SKILL.md` |
| **MIGRATE** | "migrate", "env_var", "environment variable", "convert to var", "migration", "prepare for snowflake" | ⚠️ **You MUST `Read` `migrate/SKILL.md` before taking any action.** Migration has complex, non-obvious requirements that will cause failures if skipped. Do NOT attempt migration from general knowledge. |

## ⚠️ Critical: Incremental Model Fixes Require `--full-refresh`

After fixing an incremental model's logic (e.g., restoring a missing `is_incremental()` guard, changing the unique key, or altering the incremental strategy), you **MUST** execute with `--full-refresh`. Without it, the existing table still contains data built by the broken logic — a normal incremental run only processes new rows and won't fix the bad data.

## Quick Reference

```bash
# Deploy (add --external-access-integration if project needs external network access)
snow dbt deploy my_project --source /path/to/dbt --database my_db --schema my_schema --external-access-integration MY_EAI

# PREVIEW model output (does NOT create objects)
snow dbt execute -c default --database my_db --schema my_schema my_project show --select model_name

# Execute/RUN models (creates tables/views)
snow dbt execute -c default --database my_db --schema my_schema my_project run

# Full refresh (REQUIRED after fixing incremental model logic)
snow dbt execute -c default --database my_db --schema my_schema my_project run --full-refresh

# Execute specific models with dependencies
# Upstream deps of target:
snow dbt execute -c default --database my_db --schema my_schema my_project run --select +target_model
# Downstream deps of target:
snow dbt execute -c default --database my_db --schema my_schema my_project run --select target_model+
# Both sides:
snow dbt execute -c default --database my_db --schema my_schema my_project run --select +target_model+

# List (omit --database to use connection default)
snow dbt list --in schema my_schema --database my_db

# Schedule (via SQL - always use EXECUTE DBT PROJECT)
CREATE TASK my_db.my_schema.run_dbt_daily
  WAREHOUSE = my_wh
  SCHEDULE = 'USING CRON 0 6 * * * UTC'
AS
EXECUTE DBT PROJECT my_db.my_schema.my_project ARGS = 'run';
```

## Workflow

```
User Request
     ↓
Intent Detection
     ↓
├─→ DEPLOY   → Load deploy/SKILL.md
├─→ EXECUTE  → Load execute/SKILL.md
├─→ MANAGE   → Load manage/SKILL.md
├─→ SCHEDULE → Load schedule/SKILL.md
├─→ MONITOR  → Load monitoring/SKILL.md
└─→ MIGRATE  → ⚠️ MUST Read migrate/SKILL.md first (complex requirements) → Then follow its steps exactly
```

## Stopping Points

- ⚠️ Before any destructive operation (DROP, RENAME)

## Output

- Deployed dbt projects in Snowflake
- Materialized tables/views from dbt models
- Test results from dbt test
- Scheduled TASK objects for automated execution
- Execution logs and artifacts for debugging