Menu
Pre-merge SQL quality gate — lint 26 anti-patterns, grade readability/performance A-F, validate syntax, and scan for injection threats. Use before committing or reviewing SQL changes.
Cloudflare-style AI code review for dbt/SQL pull requests. Produces a signed APPROVE/COMMENT/REQUEST_CHANGES verdict where every blocking finding is backed by a deterministic engine call — column-lineage blast radius, query equivalence, PII classification, and A–F grade. Use to review a dbt PR or the working-tree changes before merge.
REQUIRED before writing or modifying ANY dbt model. Invoke this skill FIRST whenever a task says "create", "build", "add", "modify", "update", "fix", or "refactor" a dbt model, staging file, mart, incremental, or snapshot. Skipping this skill is the leading cause of silent-correctness bugs — models that compile and `dbt build` cleanly but produce wrong values. It contains the patterns that prevent the most common such bugs encountered in real dbt projects: • Incremental high-water marks (`>=` vs `>` ties → silent row dropout) • Snapshot strategy selection (timestamp vs check, `unique_key` choice) • `LEFT JOIN + COUNT(*)` phantom rows from unmatched parents • Type harmonization in `COALESCE` / `CASE` / `UNION` legs • Date-spine completeness (every period present, even empty ones) • Off-by-one window boundaries (`BETWEEN d - (N-1) AND d` for N-wide) • Uniqueness enforcement when schema implies a key • Window-function `LIMIT` with deterministic tiebreaker • Verifying transformation correctness with dbt unit te
REQUIRED after building or modifying ANY dbt model that has columns declared in `schema.yml` / `_models.yml`. Run `altimate-dbt schema-verify --model <name>` to diff actual columns against the spec, and treat any `mismatch` verdict as "not done." The most common reason "the build is green but the tests still fail" is that the model produces the right *data values* in the wrong *column shape* — extra columns, missing columns, wrong order, wrong types. Many dbt equality tests grade the column tuple `(name, type, position)` exactly, and the agent's prior bias is to add "helpful" extras (`p1`/`p2`/`p3` rank breakdowns, name-resolved variants, lineage metadata) or reorder columns "more logically." Both break the contract. This skill enforces the mechanical check that catches those bugs before declaring done. Use it before declaring any model task complete.
Generate dbt unit tests automatically for any model. Analyzes SQL logic (CASE/WHEN, JOINs, window functions, NULLs), creates type-correct mock inputs from manifest schema, and assembles complete YAML. Use when a user says "generate tests", "add unit tests", "test this model", or "test coverage" for dbt models.
Validate that two tables or query results are identical — or diagnose exactly how they differ. Discover schema, identify keys, profile cheaply, then diff. Use for migration validation, ETL regression, and query refactor verification.
Add schema tests, unit tests, and data quality checks to dbt models. Use when validating data integrity, adding test definitions to schema.yml, writing unit tests, or practicing test-driven development in dbt. Powered by altimate-dbt.
| name | sql-review |
| description | Pre-merge SQL quality gate — lint 26 anti-patterns, grade readability/performance A-F, validate syntax, and scan for injection threats. Use before committing or reviewing SQL changes. |
Agent: any (read-only analysis) Tools used: altimate_core_check, altimate_core_grade, sql_analyze, read, glob, bash (for git operations)
Use when the user wants to:
Do NOT use for:
query-optimizedbt-troubleshootsql-translateEither:
git diff --name-only HEAD~1 | grep '\.sql$'
For dbt models, compile first to get the full SQL:
altimate-dbt compile --model <name>
Call altimate_core_check — this is the single-call code review that composes:
altimate_core_check(sql: <sql>, schema_context: <schema_object>)
Call altimate_core_grade to get an A-F quality score with per-category breakdown:
altimate_core_grade(sql: <sql>, schema_context: <schema_object>)
Categories scored:
Call sql_analyze for the detailed anti-pattern breakdown with severity levels and concrete recommendations:
sql_analyze(sql: <sql>, dialect: <dialect>)
SQL Review: <file_or_query_name>
==============================
Grade: B+ (82/100)
Readability: A (clear CTEs, good naming)
Performance: B- (missing partition filter on large table)
Correctness: A (proper NULL handling)
Best Practices: C (SELECT * in staging model)
Issues Found: 3
[HIGH] SELECT_STAR — Use explicit column list for contract stability
[MEDIUM] MISSING_PARTITION_FILTER — Add date filter to avoid full scan
[LOW] IMPLICIT_CAST — VARCHAR compared to INTEGER on line 23
Safety: PASS (no injection vectors detected)
PII: PASS (no PII columns exposed)
Verdict: Fix HIGH issues before merging. MEDIUM issues are recommended.
When reviewing multiple files (e.g., all changed SQL in a PR):
| File | Grade | Issues | Safety | Verdict |
|------|-------|--------|--------|---------|
| stg_orders.sql | A | 0 | PASS | Ship |
| int_revenue.sql | B- | 2 | PASS | Fix HIGH |
| mart_daily.sql | C | 5 | WARN | Block |
/sql-review models/marts/fct_orders.sql -- Review a specific file/sql-review -- Review all SQL files changed in the current git diff/sql-review --all models/ -- Review all SQL files in a directory