Skills and what they do

A skill is a pre-written reference the agent can pull up on demand. Each one teaches the model something it needs to do a specific kind of work well — how to write engine-specific SQL, which chart type fits which shape of data, how to structure a report, how to model raw tables.

Skills are client-side JavaScript, so there's no extra backend roundtrip, and they're free from the agent's query budget.

The seven skills

Query skill

Teaches the model how to write good analytical SQL — not just "valid SQL" but CTEs, window functions, JOINs that actually answer the question, and engine-specific idioms for Trino vs. Databricks.

This is where we try to get the model to "think like an analytics engineer" instead of "think like a chatbot writing SQL."

ECharts skill

A catalog of every chart type Databasin can render, with when to use it, the data shape it expects, an example config, and theme defaults. The skill emits a real ECharts option object — the chart you see is built straight from it.

Analysis skill

A decision tree. Given the shape of a result set ("two numeric columns and one date", "one category and two measures"), what's the right default chart? This is how the agent proposes sensible chart options when you click "Chart this."

Document skill

How to structure a report. Covers:

• Section structure (exec summary → findings → detail → appendix).
• Writing-quality examples (GOOD vs. BAD).
• When to embed a chart and when to just use numbers inline.
• Citation requirements (every claim should name its source table or query).

Used when you ask for "write me a summary" or "generate a PDF."

Semantic search skill

Kicks in when there are uploaded documents in your data context (the agent sees semanticSearch.enabled on those tables). It teaches the model how to find the right passages and cite them — and how it searches depends on the engine:

• On Trino, there's no vector search for these tables. The skill drives keyword search — case-insensitive LIKE on the document's content column — and pushes the model to expand your question into a generous set of OR terms (synonyms, abbreviations, word stems) for better recall. It deliberately avoids similarity math against the embedding column, which doesn't work in this path.
• On Databricks, it uses ai_similarity(), which scores how close your search phrase is to each chunk of text.

Either way, the answer cites specific source files, pages, and chunks so you can click straight to the passage. See Documents and chat for the full story.

Power BI skill

When a Power BI semantic model is in your data context, this skill teaches the model how to translate Power BI's DAX — measures, calculated columns, time-intelligence patterns, relationship handling — into the SQL your engine runs. It's what lets you ask a Power BI model questions in plain English. See Bring Power BI models into One.

Semantic model skill

The rulebook for building a semantic model: entity types, joins, the baseEntity/cartesian invariant that keeps joins from blowing up, and how Gold views are shaped. The agent reads this before it drafts a model with propose_semantic_model. See Build a semantic model by chatting.

How the agent decides which skill to read

The model is told, in its system prompt, that skills exist and what each is for. When it plans a turn, it decides — based on your question — whether to call one. For example:

• "Chart this" → probably reads ECharts skill + Analysis skill.
• "What's the revenue by region?" → probably reads Query skill only.
• "What did the contract say about termination?" → reads Semantic search skill first.
• "Model these tables for me" → reads Semantic model skill, then proposes a model.

You don't pick skills. You ask the question; the agent picks.

Skill compaction

Once a skill has been read and the model has produced a response based on it, the content is compacted away and replaced with a short "already read" placeholder. This keeps the conversation's token budget from ballooning over many turns.

Compaction is safe because skills are static: if the model needs the content again, it can call the tool again.

Importantly — only skills get compacted. SQL results, sample data, and schemas are never touched, because the model needs those actual values to keep reasoning.

Where to go next