Most AI knows SQL. It doesn't know how your team writes it.

Every organization runs on conventions nobody wrote down — which date column counts, which fields get masked, what "revenue" means. Skills are how you hand those to the model.

The challenge is no longer generating SQL. It's generating SQL the way your team would have.

Generating a valid query stopped being the hard part some time ago. Ask in plain language, get syntactically perfect SQL in seconds. What a general-purpose model can't know is the layer of judgement sitting on top of the syntax: your optimization patterns, your governance requirements, the standards your analysts apply without thinking about them.

The result is a query that runs, returns a number, and quietly ignores every convention that makes analytics trustworthy in your organization.

SELECT date_trunc('month', created_at) AS month, sum(amount) AS revenueFROM ordersGROUP BY 1ORDER BY 1;

What the difference actually looks like

Take the simplest possible request: show me monthly revenue trends. Here is what a general model produces, and what an analyst on your team would have written.

Generic output — valid, runs fine:

sql

With your Skills applied:

sql

SELECT date_trunc('month', o.completed_at AT TIME ZONE 'UTC') AS month, sum(o.net_amount) AS revenueFROM analytics.v_orders oWHERE o.status = 'completed' AND o.is_test = falseGROUP BY 1ORDER BY 1;

Both queries execute. Both return a monthly revenue series. They do not return the same numbers — and every difference between them comes from something a person in your company knows and a general model cannot.

Skill What it changed Date handling completed_at, not created_at — your business recognizes revenue on completion, and both columns exist. Metric definition net_amount — revenue is net of refunds here. Finance settled that two years ago. Schema logic analytics.v_orders — the curated view, not the raw table, so the grain is fixed and PII is already masked. Conventions is_test = false — the exclusion everyone applies and no schema records. Timezone Explicit UTC, so month boundaries don't drift by server.

None of those are database rules. They're organizational knowledge — the kind that lives in senior analysts' heads, gets transmitted to new hires slowly and unevenly, and is invisible to any model that only sees your schema.

What Skills are

A Skill is a reusable instruction that tells DBx how your organization does a particular kind of work. You write it once; it applies automatically whenever it's relevant.

• Postgres date handling — enforce the date functions, timezone handling and boundary conventions your reporting depends on, so two people's "last month" mean the same thing.
• Query optimization — efficient join order, index-aware predicates, fewer nested subqueries. SQL that's production-shaped, not merely correct.
• Data privacy — mask sensitive fields before display and keep restricted columns out of results, so exploration doesn't become exposure.
• Schema-specific logic — teach DBx how your relationships actually work: which join path is correct where two are possible, and which views to prefer over raw tables.

The point isn't that the model becomes smarter. It's that it stops guessing at things your organization already decided.

Skills and your semantic layer

If you already define metrics centrally, Skills sit alongside that rather than replacing it. A semantic layer answers what a metric is. Skills answer how work gets done around it — which dialect quirks to respect, which exclusions apply, what to mask, how to shape a join.

Where you have no semantic layer, a Skill is a reasonable place to record a metric definition and a much better place than nowhere. Where you do, point the Skill at it rather than restating it, so there's one source of truth and not two that drift.

Why this is the part that matters

Most organizations run on unwritten rules. Senior analysts know them, new hires absorb them over months, and every AI tool starts from zero every time. Skills turn that tacit knowledge into something the whole organization applies by default — which is also, incidentally, the fastest onboarding mechanism a data team can build.

It comes back to the thing that keeps surfacing across this whole category: producing an answer was never the hard part. Producing one you can trust is. A general model gets you the first. Your team's accumulated context is what gets you the second.

Teach DBx how you work. Skills let your team capture query standards, governance rules, privacy requirements and schema knowledge once, and apply them to every question anyone asks. Start with the three corrections your analysts give most often — that's usually the whole first version.

Query it. Analyze it. Visualize it. — all with DBx.