Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/andre-salvati/databricks-template/data-divergencenpx skills add andre-salvati/databricks-template --skill data-divergencegit clone --depth 1 https://github.com/andre-salvati/databricks-templateWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00123 | $0.02841 |
| Opus 5 | $0.00062 | $0.01421 |
| Sonnet 5 | $0.00025 | $0.00568 |
| Haiku 4.5 | $0.00012 | $0.00284 |
Grade A, and why
data-divergence scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 197 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Investigating a data divergence
Report what happened, not just what differs.
Verify the premise first. "There's a divergence between X and Y" is a hypothesis, not a finding. Reconcile before theorizing — a good share of reports turn out to be the wrong two columns compared, and saying so plainly with numbers is a complete and useful answer.
Steps
- Establish the two sides and the grain. Name the exact objects and the key that identifies one row on each side. If the two sides have different grain — one is a rollup of the other — jump to Across an aggregation boundary; a row-count comparison is meaningless there. If the complaint came from a chart, read its query first — see Dashboards.
- Count, at every layer. One
UNION ALLdown both paths — source → each intermediate → output — withCOUNT(*),MIN/MAXof the partitioning/date column, and a distinct count of the key. Find the first layer where the two sides stop agreeing; that one query eliminates everything upstream of it. - Diff by grain, then by key (below). Stop and read the pattern before forming a theory.
- Read the Delta log for the layer that first diverged (below).
- Check run state — a missing tail is a failed job, not a logic bug. Look at job/pipeline run history and events, and compare the deployed revision against the one in source control; a fix that exists in the repo but was never shipped presents exactly like a code bug that isn't there.
- Report what is proven, what is inferred, and what the retained logs can no longer answer.
On Databricks, drive all of this with execute_sql rather than shelling out. Confirm which identity
the connection authenticates as before trusting environment isolation — an MCP server or shared
service principal may reach further than your own account does.
Diff by grain, then by key
Group both sides by the dimension the report slices on and show only the buckets that differ:
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 197 lines · 123 tokens per session scan A 98154d7c7ecf
data-divergence is a skill published in the GitHub repository andre-salvati/databricks-template (83 stars, last pushed 27d ago), licensed Apache-2.0. It adds 123 tokens to every session and 2,841 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
data-parity
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.
dbt-develop
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…
data-viz
Build modern, interactive data visualizations and dashboards using code-based component libraries (shadcn/ui, Recharts, Tremor, Nivo, D3, Victory, visx). Use this skill whenever the user asks to visualize data, build dashboards, create analytics views, chart metrics, tell a data story, build a reporting interface…
dbt-troubleshoot
Debug dbt errors — compilation failures, runtime database errors, test failures, wrong data, and performance issues. Use when something is broken, producing wrong results, or failing to build. Powered by altimate-dbt.
dbt-unit-tests
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.
dbt-schema-verify
REQUIRED after building or modifying ANY dbt model that has columns declared in schema.yml / models.yml. Run altimate-dbt schema-verify --model 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…