charting-vega-lite/SKILL.md
Create interactive data visualizations using Vega-Lite declarative JSON grammar. Supports 20+ chart types (bar, line, scatter, histogram, boxplot, grouped/stacked variations, etc.) via templates and programmatic builders. Use when users upload data for charting, request specific chart types, or mention visualizations. Produces portable JSON specs with inline data islands that work in Claude artifacts and can be adapted for production.
npx skillsauth add oaustegard/claude-skills charting-vega-liteInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
This skill creates interactive Vega-Lite visualizations from uploaded data. The workflow:
Claude artifacts cannot use fetch() for computer:// URLs.
All data must be embedded as an inline JavaScript constant:
const DATA = [ /* embedded data array */ ];
// Later in chart specs:
spec.data = { values: DATA };
DO NOT:
This is the only pattern that works in Claude's artifact environment.
Execute this sequence when user uploads data without specifying chart type:
python /mnt/skills/user/charting-vega-lite/scripts/analyze_data.py /mnt/user-data/uploads/<filename>
Extract from output:
fields[] (with types and statistics)suggested_charts[] (suggested chart types with encodings)sample_data (first 10 rows for understanding context)If script fails: Use manual pandas analysis
import pandas as pd
df = pd.read_csv('/mnt/user-data/uploads/<filename>')
# Classify: numeric→quantitative, datetime→temporal, <20 unique→nominal
Read sample data and column names to infer what the data represents:
Ask: What questions would someone analyzing this data want answered?
Examples:
Filter analyze_data.py suggestions based on context and readability:
Apply readability filters:
Prioritize charts that answer domain questions:
Don't suggest charts just because data types match - choose charts that reveal insights.
Build specs programmatically using analyze_data.py encodings:
For each suggested chart type, construct spec using:
assets/templates/ for basic types (bar, line, scatter, pie, heatmap, area)references/spec-builder-patterns.md for variations (histogram, boxplot, grouped-bar, etc.)references/vega-lite-examples-inventory.md for uncommon typesStructure each chart as:
{"type": "Chart Name", "reason": "Why this chart", "spec": {/* vega-lite spec */}}
Load data, read template, replace __DATA__ and __CHART_SPECS__ placeholders, write using bash heredoc.
[View chart explorer](computer:///mnt/user-data/outputs/ChartExplorer.jsx)
Created 7 contextually relevant charts for your data.
When user specifies chart type (e.g., "make a bar chart"):
python /mnt/skills/user/charting-vega-lite/scripts/analyze_data.py /mnt/user-data/uploads/<filename>
Check requirements:
If data doesn't fit:
Use templates or programmatic builders based on chart type complexity.
Same pattern as Primary Workflow step 5, but with single chart.
Common failures:
Using fetch() in artifacts
Chart doesn't render
spec.data = {values: DATA}Generic/random chart suggestions
Scripts:
scripts/analyze_data.py - analyze structure, suggest 8-12 chart typesComponents:
assets/components/ChartExplorer.jsx - multi-chart explorer templateTemplates:
assets/templates/*.json - 6 basic chart templates (bar, line, scatter, pie, heatmap, area)References - Progressive Disclosure:
Read spec-builder-patterns.md when building charts programmatically (histogram, boxplot, grouped/stacked bars, multi-line, etc.)
Read vega-lite-examples-inventory.md when user requests uncommon chart type not in spec-builder-patterns
Read chart-types.md when validating specific chart requirements or user asks "what chart should I use for..."
Read advanced-charts.md for complete specs of specialized charts (sankey, waterfall, violin plots, complex layered compositions)
Read contextual-chart-selection.md for extended domain examples if unfamiliar with data domain (biomedical, financial, IoT, etc.)
Read online-resources.md to fetch Vega-Lite docs for advanced features (custom selections, transforms, conditional encoding)
User uploads assay data CSV (51 assays, 74 samples)
# 1. Analyze
python /mnt/skills/user/charting-vega-lite/scripts/analyze_data.py /mnt/user-data/uploads/assay_data.csv
# 2. Understand context: Multi-analyte immunoassay
# Questions: Which biomarkers strongest? Patterns across samples? Variability?
# 3. Build contextual charts (5-7 specs)
# Bar: Mean signal by assay
# Heatmap: Sample × Assay
# Box plot: Signal distribution by assay
# Histogram: Overall signal distribution
# etc.
# 4. Load data and template
df = pd.read_csv('/mnt/user-data/uploads/assay_data.csv')
data = df.to_dict(orient='records')
template = open('/mnt/skills/user/charting-vega-lite/assets/components/ChartExplorer.jsx').read()
# 5. Replace placeholders and write
artifact = template.replace('__DATA__', json.dumps(data)).replace('__CHART_SPECS__', json.dumps(charts))
# Use bash heredoc to avoid XML conflicts in tool parameters
# 6. Provide link
View chart explorer
Created 7 charts for your assay data - bar charts show biomarker signals, heatmap reveals sample patterns, box plots display variability.
development
--- name: verifying-claims description: Check that a document's claims about code are actually true by reading the prose, the code, and the tests and reporting (or fixing) where they disagree. Use whenever the user wants to verify a README, guide, spec, or docstring still matches the code; whenever they mention documentation drift, doc-code sync, "is this still accurate", stale docs, or keeping docs/tests/code consistent; before publishing or merging a docs change; or as a periodic doc-accuracy
tools
Query, filter, and transform Markdown structurally with mq — a jq-like CLI for Markdown. Use to extract headings/sections/code-blocks/links from .md files, build a table of contents, pull code blocks of a given language, slice or reshape LLM prompt/output Markdown, or batch-transform docs. Triggers on "extract sections from this markdown", "get all the code blocks", "jq for markdown", "mq", or any structural query over Markdown that grep/Read can't do cleanly.
development
Composes single-file HTML artifacts (PR review writeups, status reports, incident postmortems, slide decks, design systems, prototypes, flowcharts, module maps, feature explainers, kanban boards, prompt tuners) from a small JSON spec instead of hand-written HTML/CSS/JS. Use when the user asks to "compare options side-by-side", requests an HTML version of a report or review or deck, asks for a flowchart, status update, postmortem, design system reference, interactive prototype, custom editor — or explicitly says "HTML artifact", "single HTML file", "self-contained HTML". Skip for ad-hoc HTML snippets (forms, emails, embedded widgets) where there's no template fit.
development
DAG workflow runner that encodes control flow in code, not prose. Use when a procedure has 3+ steps with branching, retries, or validation that must be enforced — gates as `when=`, edge contracts as `validate=`, predicate loops as `retry_until=`. The runner owns the graph; the LLM provides leaves. Also covers parallel execution, checkpoint resume, detached side-effects.