flint-chart: Skill for Claude Code

flint-chart: authoring and using a chart spec

What you produce (and what you do NOT)

Your output is the spec: the chart_spec and semantic_types of a ChartAssemblyInput. You reference data columns by name. The host passes the resulting input to assembleVegaLite, assembleECharts, or assembleChartjs to get a backend spec.

You write the input spec, not the output spec. And critically:

• DO emit chart_spec (chart type, channel→field mapping, properties) and semantic_types (field → semantic type).
• DO add interaction_spec when the user asks for behaviour (highlight, legend toggle, pan and zoom, brush), asks for an interactive chart, or the session's goal is to explore the data. List presets by name; see "Interactions", and load the flint-interaction-author skill for an intent, an interactive chart with nothing named, or a combination.
• Reference columns by name. How data itself gets bound depends on the situation — a URL, a host-side variable, or embedded rows (see "How data gets bound"). Embedding is fine for small tables; just don't re-serialize a large dataset by hand, since that risks truncation and silent value corruption and wastes tokens.
• Transform data before Flint. If the requested chart needs aggregation, filtering, joins, pivots, derived columns, or long/wide reshaping beyond Flint's built-in static-series fold, use a coding, notebook, SQL, or data tool first. Then author the Flint spec against the transformed table.
• Style after Flint, only when needed. Author structure in Flint. For a presentation tweak Flint does not express (a reference line, annotation, or shaded band), use the Vega-Lite escape hatch — see "Post-Flint style customization". Never feed edited Vega-Lite JSON back to render_chart.

When the user wants more than a spec

First decide which workflow the user is asking for:

• Spec authoring only: return a ChartAssemblyInput or its semantic_types + chart_spec pieces. Do not install packages or write renderer code unless asked.
• MCP chart output: if Flint MCP tools are available, default to validate_chart then show whenever the user asks to see a chart. validate_chart checks the spec and returns a report without drawing; fix what it asks in the spec, then call show({ "chart": … }) once with the whole spec, which opens an interactive, live-rendered card with a customization panel. The server keeps nothing between calls: the spec in the conversation is the chart. Only fall back to render_chart (PNG/SVG) when the host has no App UI support or the user explicitly wants a static image. Use compile_chart when the user wants backend-native JSON, and list_chart_types when you need the supported chart catalog.
• DO pass updates beside the input to validate_chart and show when the user asks the chart to open in a state: rows to stand out, a note on a mark, a framed range. It is a list of ChartUpdate layers, state not behaviour; the shapes are in flint://interaction-skill under "Update the chart". To change a chart in a later turn, change its spec or updates and call show again: a new card shows it, earlier cards stay as they were. The reader's edits in the card's panel live on that card; its context gives the chart_spec that keeps them, so pass it unless the user asked for something else.
• DO pass view: "table" to show when the user wants to see a chart's numbers: the card opens on the table of the rows the chart draws, and the reader can switch to the chart. When the user wants records listed and no chart at all, use chartType: "Table" instead.
• Project integration, only when the user asks for code: add Flint to an app, notebook, script, or agentic product, install/import the library, and call an assembler in code. Keep the same ChartAssemblyInput contract, then let the host render the backend result.