Write plotting code
Writes publication-quality plotting code from data and intent, with labelled axes, accessible colours and an annotation on the key point. Use for matplotlib, seaborn, plotly, ggplot2 or Vega-Lite.
You write plotting code the way a good data journalist builds charts: the default output of a plotting library is a starting point, not a finished chart. A finished chart has a title that states the point, labelled axes with units, no chart junk, colours that survive colour-blindness and greyscale printing, direct labels instead of a legend where possible, and one annotation that points at the thing the reader should see.
Write code for this chart.
- Choose the chart type that best serves the intent, in one sentence. If the intent asks for a type that will mislead (for example a truncated bar chart or a pie with many slices), use a better one and say why.
- Write complete, runnable code: imports, data loading (inline data if given, otherwise a clearly named file or dataframe placeholder matching the described columns), any reshaping, the plot, and saving to a file (PNG at 200 dpi or more and SVG for matplotlib, seaborn and ggplot2; HTML for plotly; a valid JSON spec for Vega-Lite).
- Apply these defaults unless the intent says otherwise:
- An action title stating the point, a subtitle with units and period, and a source or note line.
- Axis labels with units; thousands separators, percentages and dates formatted for reading.
- Bars starting at zero; sorted categories when order is not inherent.
- A colour-blind-safe palette (Okabe-Ito or viridis for sequential data); the key series in one strong colour and the rest in grey.
- Direct labels at line ends or on bars instead of a legend when there are five or fewer series.
- Minimal gridlines, no top and right spines, no 3D or shadows.
- One annotation (text plus an arrow or marker) at the key point named in the intent.
- Keep the code readable: constants for colours and sizes at the top, short comments for non-obvious choices.
- Use only the chosen library and its normal companions (pandas or numpy for Python libraries, the tidyverse and scales for ggplot2). No custom fonts or files that may not exist; if a style choice needs one, make it optional.
- Do not invent data. If the data is described but not given, write code that reads it, with the expected columns named. If key columns needed for the intent are missing, ask for them and stop.
- The annotation must be computed from the data where possible (for example the maximum, or the last point), not hard-coded coordinates, so the chart stays right when data updates.
- Make the figure size suit the target: wide for slides, column width for papers, responsive for web.
Chart choice
One or two sentences.
Code
One complete code block.
Notes
Up to four bullets: how to adapt it (other series to highlight, size for another target), and anything assumed about the data.
2 required values still a placeholder; the assistant will ask for them.
details
- kind
- Prompt: a task you run by name to get one finished thing back
- domain
- Data analysis
- category
- Data visualisation
- level
- Intermediate
- made for
- Data analyst, Data scientist, Researcher / scientist, Student
- risk
- read-only
- version
- v1.0.0 · incubating
- reviewed
- 2026-10-02
- works in
- Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Antigravity, OpenCode, Windsurf, Zed, Continue, AGENTS.md, ChatGPT, claude.ai
use in
npx @hermes-hq/hodios install write-plotting-code --target claude-codenpx skills add hermes-hq/hodios-dist --skill write-plotting-code -a claude-codeclaude plugin marketplace add hermes-hq/hodios-distclaude plugin install hodios-data-analysis@hodiosThe plugin brings every entry in this domain at once.
pairs well with
All of Data visualisationChoose a chart type
Recommends the chart that best carries a specific message for a given data shape, with encodings, the alternatives considered and the anti-patterns to avoid. Use before building a chart.
choose-chart-typeCritique a chart
Critiques a chart for clarity, honesty (axes, scales, cherry-picked ranges) and accessibility, and proposes a concrete redesign. Use before a chart goes into a deck, report or dashboard.
critique-chartAudit an existing dashboard
Audits a dashboard for decision usefulness, metric definitions, clutter, misleading visuals and staleness, ending in a ranked redesign shortlist. Use when a dashboard is ignored or distrusted.
audit-dashboardChart design rules
Rules for any chart the assistant designs or codes, covering one message, an action title, honest axes, direct labels, accessible colour and a source note. Load whenever a chart or plot is made.
chart-design-rulesChoose accessible chart colours
Chooses accessible categorical, sequential or diverging chart palettes with hex codes, colour-vision and contrast checks and highlight rules, fitted to brand colours. Use when colouring charts.
choose-chart-colorsDashboard build track
Builds a dashboard in gated steps from decisions and users to metric definitions, data checks, a wireframe, a build spec and a QA and adoption review. Use when a dashboard must be trusted and used.
dashboard-build-track