$npx -y skills add dbt-labs/dbt-agent-skills --skill migrating-dbt-core-to-fusionUse when a user needs help triaging dbt-core to Fusion migration errors. Runs dbt-autofix first, then classifies remaining errors into actionable categories (auto-fixable, guided fixes, needs input, blocked).
| 1 | # Fusion Migration Triage Assistant |
| 2 | |
| 3 | Help users understand which Fusion migration errors they can fix themselves vs which are blocked on Fusion updates. Your role is to **classify and triage** migration issues, NOT to fix everything automatically. |
| 4 | |
| 5 | **Key principle**: Not all migration issues are fixable in your project. Some require Fusion updates. Migration is iterative — success means making progress and knowing what's blocking you. |
| 6 | |
| 7 | ## Mandatory execution order |
| 8 | |
| 9 | This skill is a strict procedure, not general guidance. |
| 10 | |
| 11 | The assistant must follow this order: |
| 12 | 1. Step 0: Ask whether to run `dbt debug` |
| 13 | 2. Step 1: Run or confirm `dbt-autofix`, then review its changes |
| 14 | 3. Step 2: Classify remaining issues |
| 15 | 4. Only after Steps 0–2 may the assistant propose or apply manual fixes |
| 16 | |
| 17 | Hard rules: |
| 18 | - Do not inspect project files before Step 0 is completed or explicitly skipped |
| 19 | - Do not classify issues before Step 1 is complete |
| 20 | - Do not edit files before presenting the autofix review and classification summary |
| 21 | - If these rules are violated, acknowledge the violation, state which step was missed, and execute that step now before continuing |
| 22 | - **Focus on errors**: For `dbt1065` package version compatibility warnings specifically (e.g. `Package '<package_name>' requires dbt version [>=1.2.0, <2.0.0]`) — ignore these. If autofix was run, it will have already upgraded packages that need upgrading. If `dbt1065` warnings persist after autofix, no manual package updates are needed. |
| 23 | |
| 24 | ## Additional Resources |
| 25 | |
| 26 | - [References Overview](references/README.md) — index of all reference material |
| 27 | - [Error Patterns Reference](references/error-patterns-reference.md) — full catalog of error patterns by category |
| 28 | - [Classification Categories](references/classification-categories.md) — detailed category definitions with sub-patterns, signals, fixes, and risk notes |
| 29 | |
| 30 | ## Repro Command Behavior |
| 31 | |
| 32 | By default this skill uses `dbt compile` to reproduce and validate errors. The command can be customized: |
| 33 | - If the user specifies a different command (e.g. `dbt build`, `dbt test --select tag:my_tag`), use that instead |
| 34 | - If a `repro_command.txt` file exists in the project root, use the command from that file |
| 35 | |
| 36 | ## Step 0: Validate Credentials with dbt debug |
| 37 | |
| 38 | **Before doing anything else**, ask the user if they'd like to verify their credentials work on Fusion. |
| 39 | |
| 40 | Ask: "Would you like to start by running `dbt debug` to verify your credentials and connection work on Fusion? This catches environment issues early before we dig into migration errors." |
| 41 | |
| 42 | ### If the user agrees: |
| 43 | Run: |
| 44 | ```bash |
| 45 | dbt debug |
| 46 | ``` |
| 47 | |
| 48 | **What to check in the output:** |
| 49 | - **Connection test**: Does it say "Connection test: OK"? If not, credentials need fixing first — this is NOT a migration issue |
| 50 | - **profiles.yml found**: Is it loading the correct profile/target? |
| 51 | - **Dependencies**: Are packages installed? |
| 52 | |
| 53 | ### If `dbt debug` fails: |
| 54 | - **Connection/auth errors**: Help the user fix their `profiles.yml` and credentials before proceeding. Migration triage can't begin until the connection works. |
| 55 | - **Profile not found**: Help locate or configure the correct profile for Fusion |
| 56 | - **Other errors**: Note them and proceed — some `dbt debug` checks may not be relevant to the migration |
| 57 | |
| 58 | ### If `dbt debug` succeeds: |
| 59 | Confirm the environment is healthy and proceed to Step 1. |
| 60 | |
| 61 | ### If the user skips this step: |
| 62 | That's fine — proceed to Step 1. But if connection errors appear later during classification, circle back and suggest running `dbt debug`. |
| 63 | |
| 64 | ## Step 1: Run dbt-autofix (REQUIRED FIRST STEP) |
| 65 | |
| 66 | **Before classifying any errors**, ensure the user has run dbt-autofix on their project. |
| 67 | |
| 68 | ### Check if autofix has been run: |
| 69 | 1. Ask user: "Have you run dbt-autofix on this project yet?" |
| 70 | 2. Check git history for recent autofix-related commits |
| 71 | 3. Check for autofix log files |
| 72 | |
| 73 | ### If NOT run yet: |
| 74 | Prompt the user to run [dbt-autofix](https://github.com/dbt-labs/dbt-autofix) (a first-party tool maintained by dbt Labs that automatically fixes common deprecation patterns): |
| 75 | ```bash |
| 76 | uvx --from git+https://github.com/dbt-labs/dbt-autofix.git dbt-autofix deprecations |
| 77 | ``` |
| 78 | |
| 79 | **Important**: Wait for autofix to complete before proceeding with classification. |
| 80 | |
| 81 | ### Understand autofix changes (CRITICAL): |
| 82 | Before analyzing any migration errors, you MUST understand what autofix changed: |
| 83 | |
| 84 | 1. **Review the git diff** (if project is in git): |
| 85 | ```bash |
| 86 | git diff HEAD~1 |
| 87 | ``` |
| 88 | |
| 89 | 2. **Read autofix logs** (if available): |
| 90 | - Look for autofix output files |
| 91 | - Check terminal output saved by user |
| 92 | - Understand which files wer |