Each Claude Code skill becomes a data analystthat answers with a chart, not a guessed join.

Three tools already connect Claude Code to a database and return an analysis. It is worth naming them plainly before claiming anything.

• Anthropic's Data plugin. Free and first-party. It connects Snowflake, Databricks, BigQuery, or any SQL database, writes the SQL, builds visualizations with /create-viz, and assembles interactive dashboards with /build-dashboard. The fastest path if you live in Claude Code and will set your own conventions.
• Kaelio ktx. Open source. It connects your warehouse read-only, never writes, and installs a semantic layer skill into Claude Code, Codex, Cursor, and OpenCode. You run and host it yourself.
• MindsDB Minds. A per-client plugin that turns a question into structured SQL against Postgres, Snowflake, or BigQuery and explains the result.

Anthropic even published the playbook. Their write-up reports that skills plus a semantic layer lifted internal analytics accuracy from about 21 percent to about 95 percent. Reusing approved queries is now the documented method, not a secret. So the wedge is not capability. Every tool above can chart your data.

A data analyst is not a tool that runs a query. It is one you can take a number from and defend in the next meeting. That takes four things.

It answers in plain English. It runs read-only, so it cannot change the data it reads. It reusesa query someone already verified instead of guessing a join. And it returns a chart with a sentence, not a wall of rows. The free plugins clear the first and the last with ease. The trust parts, read-only by enforcement and reuse of approved queries, are where most setups are still on the honor system.

Here is the difference in one example. Ask for revenue by plan. A fresh guess against the schema tends to produce this.

SELECT plan,
       SUM(i.amount_cents) / 100.0 AS revenue
FROM   subscriptions s
JOIN   invoices i ON i.customer_id = s.customer_id
GROUP  BY plan;

That joins subscriptions to invoices on customer_id and double counts every annual plan, because an annual plan has one subscription row and twelve invoice rows. The number looks plausible. It is off by twelve on exactly the plans that matter most.

SELECT date_trunc('month', billed_on) AS month,
       plan,
       SUM(amount_cents) / 100.0 AS mrr_usd
FROM   billing.subscriptions
WHERE  status = 'active'
GROUP  BY 1, 2
ORDER  BY 1, 2
LIMIT  1000;

Chion does not let the agent improvise that join. The skill must-reads a query your team already verified, so the grain is handled before the question is asked. What routes the prompt to that query is the frontmatter.

---
name: finance-analyst
description: Use when answering revenue, MRR, ARR, churn, or cohort questions on the production Postgres warehouse.
triggers: [revenue, mrr, arr, churn, cohort, ltv]
must-read:
  - CHION.md
  - personas/finance-analyst/_INDEX.md
profiles:
  portable: true
  claude_code: true
---

The description starts with "Use when" so the router matches it. The triggers carry the vocabulary. The must-read points at the CHION.md that holds the verified queries and the read-only rules. Run the same question in Chion and the answer comes back as an interactive chart with one sentence on what changed.

The first time I pointed an agent at our billing schema, the join above is exactly what it produced. I spent ten years writing these queries at Meta, Twilio, and American Express, and the model still made the join a junior analyst makes on day one. The fix was never a sharper prompt. It was reuse.

Then a schema change. We renamed amount_cents to amount_minor across the warehouse, and every hand-written skill that referenced the old column broke quietly. The compiled skills picked up the new column on the next refresh, because they are built from the live verified queries, not a snapshot of prose. That durability is the lived version of our Claude Code skill for SQL that survives schema changes.

A plugin or an open-source CLI gives you the engine. You still assemble the connection, the semantic layer, the query library, and the access rules, and you maintain them as your schema moves. Chion is the hosted version of that work. You open a browser, connect a read-only Postgres role, promote the queries you trust, and the analyst is governed for the whole team: an AES-256-GCM credential vault, a 1,000-row cap, an immutable audit log, billing, and tenant isolation. The person asking the question never touches a terminal.

We render the answer as interactive D3 in the browser rather than the Python charts a plugin emits, because the person asking why signups fell is usually not the person who can run a notebook. They need to hover a bar, not re-run a script.

Every cell here comes from the tool's own page, checked in June 2026. The top four rows are table stakes. The bottom two, shaded, are where Chion is a different kind of thing.

If you only need a quick text answer from a warehouse and will set your own rules, the free Data plugin or open-source ktx are genuinely strong, and you may not need Chion.

The honest split is about who you are. If you live in a terminal and want to wire it up yourself, the free Data plugin or open-source ktx are good choices. Chion earns its place when a non-engineer needs the analyst without building the stack, and a team needs governance around it.

The analyst Chion compiles is the AI SQL analyst you own. The file it exports is CHION.md. The authoring model behind both is the Claude Code skill for SQL.