Claude for Data Analysis: What to Offload, What to Keep

Hand Claude a CSV and ask it to “analyze this” and you’ll get something back fast: a few averages, a chart, a paragraph of observations. Whether any of it is safe to put in front of a stakeholder is a different question. The default behavior is confident regardless of whether the underlying arithmetic is right, and a spreadsheet with 40,000 rows hides its errors well.

We run SkillProof, a catalog where every skill gets installed on a clean machine and tested against real work before we publish a verdict. This guide covers the data category: what analysts actually hand off to Claude once the right skill is installed, what stays manual no matter how good the tooling gets, and a full worked example from a messy export to a narrative someone can act on.

What analysts actually offload

Three tasks make up most of the value, and none of them are “do the analysis for me.”

Cleaning. Real exports arrive with mixed date formats, duplicate customer IDs from a CRM merge, and units that switch between rows because someone edited the source sheet by hand. This is mechanical, tedious, and exactly the kind of work where a tired analyst introduces new errors while fixing old ones. It’s also the single biggest time sink before any actual analysis starts.

Query writing. Translating “which customers churned after their second renewal but before their third” into a correct window-function query against a schema you half-remember. Claude is good at SQL. It’s less good at knowing your schema’s quirks unless you tell it, which is the actual skill in this category: getting the model to ask about foreign keys and null conventions instead of guessing.

Turning numbers into a narrative. A dashboard tells you the number moved. It doesn’t tell you why, or whether anyone should care. Writing “signups dropped 12% this week, concentrated in the mobile funnel, coinciding with the App Store update on Tuesday” from a metrics export is writing, not math, and writing is what language models are built for.

What doesn’t move to Claude, even with a good skill installed: deciding which metric matters, judging whether a result is practically significant versus merely statistically significant, and any inference that rests on assumptions about how the data was collected. A skill can compute a p-value correctly. It cannot tell you whether your sample was actually random, because that’s a fact about your process, not your dataset.

The tested data stack

Every skill below was installed clean and run against a real file, not a demo CSV built to make the skill look good. Scores are out of 10, weighted from install, trigger, output and docs criteria. Full method on our methodology page. If you haven’t installed a skill before, our install guide covers the two-command setup for each surface.

Data Cleaning (8.8/10, pass) is the one to install first if your data comes from anywhere other than a clean internal database. Our test threw a 60,000-row export at it with mixed date formats, duplicate keys, and unit inconsistencies between columns that should have matched. It fixed all three categories and, more importantly, produced a change log listing every transformation it made. That log is the difference between trusting a cleaned file and hoping it’s fine. Without it, “Claude cleaned your data” means “an opaque process altered your numbers,” which is not something you can defend in a meeting when someone asks why a total shifted.

SQL Query Writer (9.2/10, pass) is the highest score in the category. We tested it against a 12-table schema with the kind of query that makes analysts groan: cohort buckets with window functions and correct timezone handling. We verified the output row by row against a hand-written equivalent and it matched. Trigger score is a perfect 5, meaning it fires reliably on natural requests like “show me weekly cohort retention” without you naming the skill or reminding it what a window function is.

Statistical Analysis (8.8/10, pass) ran significance tests and a regression against a marketing dataset in our test. The result worth noting: when we asked it to draw a causal conclusion the data couldn’t support, it declined and explained why, rather than producing a confident-sounding paragraph anyway. That refusal is the entire point of this skill existing. A tool that always gives you an answer is worse than one that sometimes says the question is unanswerable from what you have, because the first kind trains you to stop checking.

Dashboard Builder (8.0/10, pass) turns a CSV into a self-contained interactive dashboard. Our test used a revenue CSV and got back correct chart types with no chartjunk, readable at a glance. It scored lower than the others mostly on docs, a 3 out of 5, because the README undersells what it needs from you before the first run: a clean header row and a decision about which column is the time axis.

Metrics Review (7.2/10, works with setup) is what the weekly narrative use case above is built on, and the narrative it produced, with anomalies called out, was genuinely useful in testing. The catch: it needs your metrics export or an analytics MCP connection wired up first, and that setup step isn’t optional. Budget twenty minutes before the first real run, and expect to answer a few questions about which metrics actually matter to your team.

Chart Critic is still in our test queue. We’re running it against a set of deliberately misleading charts to see what it actually catches before we publish a verdict. Worth watching if chart honesty is a recurring problem on your team, but not yet something we can vouch for.

A worked workflow: export to narrative

Here’s what the stack looks like chained together, using a weekly revenue review as the example.

1. Messy export. Finance drops a CSV pulled from three billing systems after an acquisition. Dates are in two formats depending on which system exported the row, one system uses cents and the other uses dollars, and about 200 customer IDs appear twice because of a botched migration.

2. Cleaned dataset. Data Cleaning normalizes the date formats, flags the unit mismatch and asks which currency convention to standardize on rather than guessing, and de-duplicates the customer IDs using the migration’s own key mapping. You get a clean file and a change log. Read the log before moving on. This is the checkpoint where you catch a wrong assumption before it propagates into every number downstream.

3. SQL. With the cleaned data loaded, SQL Query Writer builds the actual aggregation: revenue by cohort, by plan tier, week over week, with correct handling of mid-month upgrades. This is where “which customers actually renewed” gets answered precisely instead of approximately.

4. Weekly narrative. Metrics Review takes the query output and the prior week’s numbers and writes the summary: what moved, by how much, and what coincided with it. “Enterprise tier revenue held flat but seat count dropped 8%, consistent with the pricing change that took effect the 3rd.”

Four steps, four different kinds of work, and each one benefits from a skill built specifically for it rather than one skill trying to do all four badly. This is the same reason we don’t recommend a single “do data analysis” skill: cleaning, querying, statistics and narrative writing are different disciplines that happen to share a spreadsheet.

The trust problem

The uncomfortable fact about language models and numbers: a model can produce a plausible, well-formatted, entirely wrong figure, and nothing about its tone will tell you which kind of answer you got. This isn’t a minor bug to patch around. It’s a structural property of how these models generate text, and it’s the reason “Claude said the number is X” should never be the last line of verification on anything that goes in a board deck.

What actually mitigates this, from what we’ve seen in testing, is not a smarter model. It’s an audit trail. Data Cleaning earned its 8.8 partly because its change log lets you check every transformation against the source file. Statistical Analysis earned its trust the same way: not because it’s always right, but because when it isn’t confident, it says so instead of filling the gap with a plausible-sounding number.

The rule we’d suggest, and the one we follow ourselves: never ship an unchecked figure. If a number is going into a report, a deck, or an email to someone who’ll make a decision based on it, trace it back to the query or the cleaning step that produced it. That’s a five-minute check against a spreadsheet you can open yourself. It is much cheaper than the meeting where someone asks where the number came from and the honest answer is “Claude said so.”

Where Excel and documents cross over

A lot of real analysis doesn’t end in a dashboard. It ends in a spreadsheet someone else opens, edits, and forwards. This is where the xlsx skill matters, scoring 9.2/10 in our testing on a 40,000-row export with malformed headers, formula columns, and a pivot summary sheet.

The detail that actually matters here: it writes working formulas, not frozen values. A pasted number is dead the moment the source data changes. A live SUMIFS or a pivot table updates when the underlying rows do, which is the entire reason spreadsheets survive the way markdown reports don’t. If Claude hands back a column of numbers where a formula should be, you’ve gained a snapshot and lost a spreadsheet.

We cover the full document skill set, including where PDF and Word fit into an analyst’s actual workflow, in our documents guide.

What we wouldn’t automate

Here’s the stance: don’t let Claude run statistical inference you couldn’t check yourself. Not because the model is bad at the math, our tests suggest it usually isn’t, but because the moment you can’t evaluate whether an assumption held (independence, sample size, selection bias in how the data was collected), you’ve lost the ability to catch it when it’s wrong. A regression with a violated assumption still prints a coefficient. It just doesn’t mean what you think it means, and if you didn’t understand the method going in, you won’t notice the output lying to you.

This isn’t a call to avoid statistics. It’s a call to keep the boundary where it belongs: use the skill to do the arithmetic faster, not to substitute for understanding what the arithmetic is claiming. If a result would change a real decision, either you understand the method well enough to sanity-check it, or you find someone who does before it ships.

FAQ

Can Claude actually analyze a real dataset, not just a demo CSV?

Yes, with a caveat. Our tests specifically avoided clean demo files: the Data Cleaning test used a genuine 60,000-row export with the kind of mess real systems produce, and it held up. General-purpose Claude without a skill installed does a rougher, less accountable version of the same task. The skill’s value is mostly in the audit trail, not in raw capability the base model lacks.

Does Claude replace a data analyst?

No, and the parts it doesn’t touch are the job’s actual substance: deciding what question is worth asking, judging whether a result matters to the business, and catching a flawed assumption before it becomes a wrong conclusion. It replaces the mechanical middle: cleaning, querying, first-draft narrative. That’s real time saved, not the whole job.

How do I check Claude’s data cleaning before I trust it?

Read the change log. A cleaning skill worth using produces one: every date reformatted, every duplicate merged, every unit conversion applied, listed against the original rows. If a skill cleans your data silently with no log, treat the output as unverified regardless of how good it looks.

Which skill should I install first if I only pick one?

Data Cleaning. Almost every downstream task, SQL, statistics, dashboards, depends on the input being trustworthy, and cleaning is the step most people skip or do carelessly under deadline pressure. Our best data skills page ranks the full stack if you want the shortlist beyond this one.

Can Claude write formulas in Excel, or does it just paste numbers?

With the xlsx skill installed, it writes live formulas: SUMIFS, pivot tables, lookups that recalculate when source rows change. Without the skill, or with a generic request, you’re more likely to get static values that look right on export day and go stale the moment the data updates.