What do I need to prepare before starting?

The data as a file (sales.csv), the one question the chart should answer, who's looking at it (exec slide vs. analyst review), and one number you already trust — like last month's total revenue — to sanity-check the underlying data before you render anything.

Is it safe to chart data that includes customer-level detail?

Aggregate before you chart — show revenue by region, not by named account — and keep the source CSV local. The chart should show the pattern, not expose identifying rows. If the data is customer-level, do the aggregation step first and confirm the chart contains no personally identifying information before sharing it.

What if the numbers don't look right after the verify step?

Stop and run the Find out why the number moved playbook before charting anything. Never put a number you can't reconcile in front of an exec — a chart launders data and makes wrong numbers look authoritative. Fix the discrepancy first, then render.

Can I adapt this to a recurring slide deck?

Yes — once the chart types and prompts are set, save them as a /chart custom command or skill so next month's deck is one command. The Build a recurring analysis report capstone reuses exactly these charts as part of its pipeline.

From a raw CSV to a chart you can paste into a slide

when to reach for this

You have sales.csv and a slide that needs a chart by end of day. The trap is jumping straight to "make me a bar chart" — you get a chart, but is it the right view, are the axes labeled, and are the numbers behind it even correct? A chart launders data: once it's a clean image, nobody re-checks the math. This system goes from raw CSV to a paste-ready PNG the honest way — pick the view that answers the question, render it with real titles and labels, and verify the numbers before anyone sees them.

gather this first

The data as a file — sales.csv — already profiled if possible (run Interview a dataset before you touch it first so you trust the columns).
The one question the chart should answer ("is revenue trending up?", "which region is biggest?") and who's looking at it — an exec slide and an analyst review want different charts.
A number you already trust for a sanity check — last month's total revenue, a figure from a prior report — so you can confirm the chart's underlying data ties out.

the workflow

Pick the view before drawing anything

The chart type should follow from the question, not the other way around. In Claude Desktop, open the folder with your CSV and ask in the chat — no terminal needed. Trend over time wants a line; comparing categories wants bars; parts of a whole rarely wants a pie. Decide the view — and the exact aggregation — before any picture exists.

you ask

From sales.csv, I need to show whether revenue is trending up over the year, for an exec slide. Don't draw anything yet — recommend the right chart type, tell me exactly what you'd put on each axis and how you'd aggregate (e.g. revenue summed by week vs by month), and name one alternative view and why you'd reject it for this audience.

what you get back "A line chart, revenue summed by month on the y-axis, month on the x-axis — cleaner than weekly for an exec. I'd reject a stacked bar by region; it answers a different question (mix, not trend)." You've chosen the view deliberately, not by default.

Letting the question pick the chart — not the other way round — is what separates a chart that informs from one that just decorates the slide.
Verify the underlying numbers first

Check the math before it becomes a picture. Once the data is a clean line, nobody questions it — so question it now, while it's still numbers, by tying it to something you already trust.

you ask

Before charting, show me the monthly revenue table you'd plot — the actual numbers per month. Does the total across all months match last month's report figure of $480K for the period it covers? Flag any month that looks like an outlier or has suspiciously few rows behind it.

what you get back A small table — "Jan $38K, Feb $41K … total $476K" — plus a reconciliation: "matches your $480K within rounding; March is low because only 12 days of data exist that month." Now you trust the numbers before they become a chart.
Generate the chart as a labeled image file

Render it to an actual PNG you can drop into a deck — with a title, axis labels, and units. An unlabeled chart is a screenshot of a guess; the labels are what make it standalone.

you ask

Now make the line chart of monthly revenue and save it as revenue-by-month.png at slide resolution. Title it 'Revenue by Month, 2026', label the y-axis 'Revenue (USD)' with thousands formatted as $40K, label the x-axis with month names, and note the data source and date range in a small caption.

what you get back A saved revenue-by-month.png you can paste straight into the slide: titled, both axes labeled with units, dollars formatted readably, and a caption stating it's from sales.csv through the data's actual end date.

Always have Claude write the chart to a named image file — then you grab the PNG straight from the file pane in Claude Desktop, rather than retyping anything or screenshotting it.
Build the mini-dashboard or annotate the takeaway

One chart rarely tells the whole story; a few small ones, or one chart with the insight called out, does. Add the supporting views and the one-line 'what this shows' so the slide makes its own argument.

you ask

Add two supporting charts saved as PNGs: revenue by region (bar) and month-over-month growth percent (line). Lay all three out as one dashboard image, dashboard.png, with a single headline at top stating the main takeaway in plain English — and annotate the biggest month directly on the trend line.

what you get back A dashboard.png with three labeled charts and a headline like "Revenue up 22% over the year, led by the West region" — a self-contained slide that makes its point without you narrating it.

make it your own

Different question, different chart: swap the step-1 ask for a comparison ('which region is biggest') and Claude picks bars over a line — the verify, render, and label discipline is identical regardless of chart type.
Charts for an Arabic-reading audience: if the slide is for an Arabic board or report, ask for the title, axis labels, and caption in Arabic with a right-to-left layout — authored in Arabic, not translated after the fact, so the wording reads native to the reader. Keep the underlying figures identical across the English and Arabic versions; only the words change, never the numbers.
It's a recurring slide (Power Track): once the views are set, save the prompts as a /chart custom command or skill (see the Capabilities tab) so next month's deck is one command — and the Build a recurring analysis report capstone reuses exactly these charts.
Numbers don't look right: if the verify step in this playbook surfaces a number you can't explain, stop and run Find out why the number moved before you chart it — never put a number you can't reconcile in front of an exec.

watch out for

A chart makes any number look authoritative, including a wrong one. Verify the underlying table before you render — once it's a clean image, the math gets a free pass it didn't earn.
If the data is sensitive — customer-level revenue, anything identifying — aggregate before you chart (revenue by region, not by named account) and keep the source CSV local; the slide should show the pattern, not expose the rows.
Claude renders the chart; you own what it claims. Read the title and the takeaway headline as carefully as the data — an overstated 'revenue is soaring' on a chart that shows a 3% bump is a claim a human has to stand behind.
A chart is a published claim that outlives the conversation. Once it's a clean image it gets pasted into decks you'll never see again, with the underlying math no longer attached. Put the source file and date range in the caption, keep the headline honest about the size of the move, and treat the chart as something your name is on wherever it travels — because at enterprise scale, it will travel.

you'll end up with A paste-ready PNG — or a three-chart `dashboard.png` with a plain-English headline — built from a deliberately chosen view, labeled properly, and backed by numbers you reconciled before anyone saw the picture.

Questions people ask

What do I need to prepare before starting?: The data as a file (`sales.csv`), the one question the chart should answer, who's looking at it (exec slide vs. analyst review), and one number you already trust — like last month's total revenue — to sanity-check the underlying data before you render anything.
Is it safe to chart data that includes customer-level detail?: Aggregate before you chart — show revenue by region, not by named account — and keep the source CSV local. The chart should show the pattern, not expose identifying rows. If the data is customer-level, do the aggregation step first and confirm the chart contains no personally identifying information before sharing it.
What if the numbers don't look right after the verify step?: Stop and run the *Find out why the number moved* playbook before charting anything. Never put a number you can't reconcile in front of an exec — a chart launders data and makes wrong numbers look authoritative. Fix the discrepancy first, then render.
Can I adapt this to a recurring slide deck?: Yes — once the chart types and prompts are set, save them as a `/chart` custom command or skill so next month's deck is one command. The *Build a recurring analysis report* capstone reuses exactly these charts as part of its pipeline.