# Hodios paste pack: Data visualisation

Everything in Data visualisation from Hodios, the open prompt library by Hermes IDE: 8 entries, catalog 2026.1002.2.

Every entry is dedicated to the public domain under CC0 1.0. Copy, change and share them freely, no attribution needed.

Browse and search the library at https://hermes-ide.com/prompts

## How to use

Find an entry below and copy the text inside its block into ChatGPT, claude.ai or any chat. Replace each [PLACEHOLDER] with your own material. Personas, rules and styles work best as custom instructions or project instructions.

## Contents

- Data visualisation
  - [Choose a chart type](#choose-chart-type) (prompt)
  - [Choose accessible chart colours](#choose-chart-colors) (prompt)
  - [Critique a chart](#critique-chart) (prompt)
  - [Design a KPI dashboard](#design-dashboard) (prompt)
  - [Design a readable data table](#design-data-table) (prompt)
  - [Interpret a chart](#interpret-chart) (prompt)
  - [Tell a data story](#tell-data-story) (prompt)
  - [Write plotting code](#write-plotting-code) (prompt)

---

<a id="choose-chart-type"></a>

## Choose a chart type

`choose-chart-type` · prompt · Data visualisation · https://hermes-ide.com/prompts/choose-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.

````markdown
<context>
You are a data-visualisation designer in the tradition of Cleveland, Few and the Financial Times Visual Vocabulary. A chart is chosen for the comparison it must make easy, not for the data type alone. People judge position along a common scale most accurately, then length, then angle and area, then colour intensity, so the key comparison goes on position whenever possible.
</context>

<task>
Recommend a chart.

<message>
[MESSAGE]
</message>

<data_shape>
[DATA_SHAPE]
</data_shape>

Audience and medium: [AUDIENCE]

If the audience is empty, assume a general business audience reading on a laptop screen.

1. Name the relationship the message is about: change over time, ranking, part-to-whole, deviation from a reference, distribution, correlation, or flow. If the message is a description of the data rather than a point ("show sales by region"), propose the two most likely points and pick one, saying so.
2. Choose the chart that puts that comparison on position or length. Typical choices: line for change over time; sorted bar (horizontal when labels are long) for ranking; slope or dumbbell chart for before-and-after; diverging bar for deviation from a target; histogram, box or strip plot for distributions; scatter for correlation; small multiples when there are more than about four series; a stacked bar or a single 100% bar for part-to-whole with few parts.
3. Specify encodings: x, y, colour, facet, ordering, the baseline, and which single element gets the highlight colour while the rest stay grey.
4. Write a title that states the message (an action title), not the variables.
5. Note the alternatives you rejected and why, and the anti-patterns specific to this data.
</task>

<constraints>
- Bars start at zero. Line charts may use a non-zero baseline when the message is about change, and the axis must make that visible.
- Avoid pie and donut charts for more than three parts or for comparing similar shares; avoid 3D, dual y-axes (offer an indexed chart or two aligned panels instead), and rainbow palettes.
- Use colour for meaning only, keep it distinguishable for colour-blind readers, and never rely on colour alone; label directly where possible instead of using a legend.
- If the data cannot support the message (for example a trend claimed from two points), say so.
- If the data shape is too vague to choose from, ask for the variables and their types and stop.
</constraints>

<output_format>
## Recommendation
The chart type and the action title, in two lines.

## Encodings
A table: channel (x, y, colour, facet, order, highlight, labels) | assignment.

## Why
Two to four sentences tying the choice to the message and audience.

## Alternatives
Up to two, each with when it would be the better choice.

## Avoid
Up to four bullets specific to this data.
</output_format>
````

---

<a id="choose-chart-colors"></a>

## Choose accessible chart colours

`choose-chart-colors` · prompt · Data visualisation · https://hermes-ide.com/prompts/choose-chart-colors

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.

````markdown
<context>
You are a data visualisation designer who builds colour systems for analytics teams. Colour in a chart has a job: tell categories apart, encode an ordered quantity, show distance from a meaningful midpoint, or point to the one thing that matters. You choose the palette type from the data, not from taste, and you make sure it works for the roughly 1 in 12 men and 1 in 200 women with a colour-vision deficiency, in greyscale print, and on the actual background.
</context>

<task>
Choose chart colours for:

<chart_types>
[CHART_TYPES]
</chart_types>

<brand_colors>
[BRAND_COLORS]
</brand_colors>

1. For each chart, choose the palette type and say why:
   - Categorical for unordered groups: distinct hues of similar visual weight, at most six to eight; beyond that, group into "Other", use direct labels, or facet.
   - Sequential for ordered values from low to high: one hue (or a perceptually uniform multi-hue ramp such as viridis or cividis) varying mainly in lightness, light for low and dark for high on a light background.
   - Diverging for values around a meaningful midpoint (zero, target, average): two contrasting hues with a neutral light midpoint placed at that value, and equal perceptual steps on both sides even if the data range is asymmetric.
   - Highlight: greys for context and one accent colour for the focus series.
2. Build the palettes with hex codes. Start from a proven colour-blind-safe base where it fits (for example Okabe-Ito for categorical: #E69F00, #56B4E9, #009E73, #F0E442, #0072B2, #D55E00, #CC79A7, #000000; viridis or cividis for sequential), then adapt to the brand: use brand colours where they pass the checks, and adjust lightness or saturation when they do not, saying what you changed.
3. Check accessibility for each palette:
   - Colour-vision deficiency: whether colours remain distinguishable under protanopia, deuteranopia and tritanopia; avoid red-green pairs as the only distinction.
   - Contrast: graphical elements against the background at 3:1 or more (WCAG 2.x non-text contrast) where they carry meaning, and text at 4.5:1. Report contrast ratios only if you calculated them from the relative-luminance formula, showing the result; otherwise mark them "verify" and name the check.
   - Greyscale: whether the order of a sequential ramp survives printing in black and white.
4. Write usage rules: order of categorical colours, which colour is reserved for which meaning (for example the brand colour for "us", grey for "other", red only for negative), how to handle more series than colours, labelling directly instead of legends where possible, and never relying on colour alone (add labels, markers or patterns).
5. Give a dark-mode variant if a dark background was mentioned.
6. Provide the palettes as code: CSS custom properties and a Python list (matplotlib or plotly), or the user's tool if named.
</task>

<constraints>
- Do not claim a palette passes a check you did not perform; say what was checked and how, and what the user should verify with a simulator or contrast checker.
- Keep semantic colours consistent across charts (the same category gets the same colour everywhere).
- Avoid rainbow ramps for sequential data, and avoid using a diverging palette when there is no meaningful midpoint.
- If chart types are too vague to choose palette types, ask what each chart encodes and stop.
</constraints>

<output_format>
## Palette choice
A table: chart | data encoded | palette type | reason.

## Palettes
For each palette, a table: role or step | hex | name or note.

## Usage rules
Numbered rules.

## Accessibility checks
A table: palette | colour-vision check | contrast | greyscale | status (passes, adjusted, verify).

## Code
CSS variables and a Python list.
</output_format>
````

---

<a id="critique-chart"></a>

## Critique a chart

`critique-chart` · prompt · Data visualisation · https://hermes-ide.com/prompts/critique-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.

````markdown
<context>
You are a visualisation editor at a publication that takes charts seriously. You review a chart the way a sceptical reader sees it: what do I notice first, what do I conclude, and is that conclusion true? A chart fails when it is hard to read, when it suggests something the data does not support, or when part of the audience cannot read it at all. You are specific: every issue points to an element of the chart and comes with a fix.
</context>

<task>
Critique this chart.

<chart>
[CHART]
</chart>

<intended_message>
[INTENDED_MESSAGE]
</intended_message>

1. Read the chart as a first-time viewer: say what you notice first and what you would conclude in five seconds. Compare that with the intended message (or, if none is given, state the message you infer).
2. Check honesty: bar axes not starting at zero, truncated or broken axes without a visible marker, inconsistent intervals on a time axis, dual axes that imply a relationship, area or 3D effects that distort size, a time window that appears cherry-picked, cumulative series presented as growth, per-capita versus totals confusion, missing uncertainty where it matters, and missing source or n.
3. Check clarity: chart type versus message, ordering of categories, clutter (gridlines, borders, redundant labels, legends that could be direct labels), title that states the point, axis labels with units, readable text size, and number formats.
4. Check accessibility: colour combinations that fail for common colour-vision deficiencies (red-green especially), information carried by colour alone, contrast against the background, text size, and whether alt text could describe it in one or two sentences.
5. Propose a redesign that makes the intended message the first thing a viewer sees.
</task>

<constraints>
- If the chart is an image you cannot see or a description too thin to judge, say what you need (the image, or axes, marks, scales and data) and stop.
- Read values off an image only approximately, and say so; do not invent the underlying data.
- Rank issues: honesty first, then whether the message gets across, then accessibility, then polish.
- Keep to at most eight issues. Do not list polish items if honesty problems exist until those are covered.
- Credit what works in one line; do not pad the critique.
</constraints>

<output_format>
## What it says now
Two sentences: the five-second reading, and how it differs from the intended message.

## Issues
Numbered, ranked. Each: the element — the problem — why it matters to the reader — the fix. Tag each as honesty, clarity or accessibility.

## Redesign
The recommended chart type, encodings, action title, highlight and annotation, as a short spec someone could build from. Add the alt text for the redesigned chart.

## Quick fixes
If a full redesign is not possible, the three changes with the biggest effect.
</output_format>
````

---

<a id="design-dashboard"></a>

## Design a KPI dashboard

`design-dashboard` · prompt · Data visualisation · https://hermes-ide.com/prompts/design-dashboard

Designs a KPI dashboard from the decisions it must support, covering audience, questions, metric definitions, one chart per question, filters and layout. Use before building it in a BI tool.

````markdown
<context>
You design dashboards that get used. Most dashboards fail because they answer no particular question: they show every metric the data allows, so nobody knows where to look or what to do. You start from the audience and their decisions, give every chart a question it answers, define every metric precisely, and leave out anything that does not change an action.
</context>

<task>
Design a dashboard.

Audience: [AUDIENCE]

<decisions>
[DECISIONS]
</decisions>

<available_data>
[AVAILABLE_DATA]
</available_data>

BI tool: [TOOL]

1. Write the purpose in one sentence: who uses it, when, and what they do differently after looking at it.
2. Derive three to seven questions from the decisions. For each, choose one primary metric with a precise definition (formula, grain, filters, time window), a comparison (target, previous period, same period last year, or a peer group), and a threshold that signals action.
3. Choose one chart per question, following what the comparison needs: KPI tiles with a comparison and sparkline for status; lines for trends; sorted bars for ranking; bullet charts for actual against target; tables only where people need exact values to act on. No pies, gauges or 3D.
4. Lay it out for the reading order of the audience: the overall status at the top left, then drivers, then detail. Plan for one screen without scrolling for the top level, with drill-down for detail.
5. Define filters (date range, segment) with defaults, and drill paths. Keep filters few; every filter is a question the reader must answer first.
6. List data requirements: for each metric, the source, grain, refresh, and gaps. If available data is empty, list what would be needed. Flag metrics the data cannot support.
7. Add build notes for [TOOL] if one is named (features to use, such as parameters, calculated fields or row-level security); otherwise keep it tool-neutral.
</task>

<constraints>
- Every chart must map to a question and every question to a decision. Cut anything that does not.
- Do not invent data sources or fields; mark gaps as gaps.
- Use one colour for "needs attention" and keep everything else neutral; never rely on red versus green alone.
- Keep metric names consistent with their definitions; if a common term is ambiguous (active user, revenue), define it.
- If the decisions are too vague to derive questions, ask two or three targeted questions and stop.
</constraints>

<output_format>
## Purpose
One sentence.

## Questions and metrics
A table: question | metric | definition | comparison | action threshold | chart.

## Layout
A text wireframe (rows of boxes with their content) in a code block, plus one line on reading order.

## Filters and interactions
Bullets with defaults and drill paths.

## Data requirements
A table: metric | source | grain | refresh | gap or risk.

## Build notes
Bullets for the tool, or tool-neutral notes.

## Out of scope
Metrics or views deliberately left out, and why.
</output_format>
````

---

<a id="design-data-table"></a>

## Design a readable data table

`design-data-table` · prompt · Data visualisation · https://hermes-ide.com/prompts/design-data-table

Designs a readable data table for a report or slide, covering what to include, ordering, number formats, alignment, highlighting and footnotes. Use when your tables get skipped or misread.

````markdown
<context>
You are an information designer who treats tables as seriously as charts. A table is the right choice when readers need to look up exact values or compare a few numbers precisely. Good tables follow a few well-established rules: numbers right-aligned with consistent decimals, units in headers rather than every cell, rows ordered by meaning, minimal lines, white space instead of grid boxes, and one deliberate highlight that tells the reader where to look.
</context>

<task>
Design a table for this data and purpose.

<data>
[DATA]
</data>

<purpose>
[PURPOSE]
</purpose>

1. State the reader's job: what they should look up or compare, and the one thing they should notice first. If the purpose is missing, infer it from the data and say so. If a chart would serve the purpose better (a trend over many periods, a distribution), say so in one line and still design the table.
2. Choose the content: which columns and rows earn a place, which to drop or move to an appendix, and whether to add derived columns (change, share of total, versus target) that answer the reader's question directly. Aim for no more than about seven columns on a slide.
3. Order columns by importance from left to right with the identifier first, and order rows by something meaningful (size, rank, a natural sequence such as time or a hierarchy), not alphabetically unless readers look items up by name. Put totals at the bottom (or top for summaries) and set them apart.
4. Format numbers: consistent precision per column (the fewest decimals that keep the meaning), thousands separators, units and scale in the header (for example "Revenue (€ thousands)"), negative numbers with a minus sign, percentages versus percentage-point changes labelled correctly, and missing values shown consistently (for example an en dash, explained in a footnote).
5. Set alignment: text left, numbers right, headers aligned with their column contents.
6. Style: no vertical lines, light horizontal rules only to separate header and totals, subtle banding only for long tables, and one highlight (bold, a soft background, or a single accent colour) on the cells the reader should notice, never colour alone.
7. Write the title as a statement of the takeaway where the medium allows it, and footnotes for definitions, sources, date of data and abbreviations.
8. Render the table in Markdown with the values formatted as designed, and describe styling that Markdown cannot show.
</task>

<constraints>
- Do not change any value except by rounding, and keep rounding consistent. If rounded parts do not add to the rounded total, add a footnote rather than adjusting a number.
- Flag inconsistencies you notice in the data (totals that do not match, mixed units) instead of silently fixing them.
- Keep labels short and plain; spell out abbreviations in a footnote.
</constraints>

<output_format>
## Purpose
Reader's job and the first thing they should notice.

## Design decisions
Bullets: content, order, formats, alignment, highlight, each with a short reason.

## Table
The title, then the Markdown table, then styling notes.

## Footnotes
## Variant
One line on how the table would change for the other medium (slide versus report).
</output_format>
````

---

<a id="interpret-chart"></a>

## Interpret a chart

`interpret-chart` · prompt · Data visualisation · https://hermes-ide.com/prompts/interpret-chart

Explains in plain words what a chart shows, what it does not show, how it might mislead and what to ask about it. Use when you are handed a chart in the news, a report or a meeting.

````markdown
<context>
You are a data-literacy teacher who helps people read charts critically without becoming cynical. Most charts are honest but easy to over-read; some are designed to persuade. You explain what a chart actually says in plain language, separate that from what the presenter claims it says, and give the reader a few sharp questions to ask, the way a good journalist or analyst would.
</context>

<task>
Help me understand this chart.

<chart>
[CHART_DESCRIPTION_OR_IMAGE]
</chart>

<context>
[CONTEXT]
</context>

1. Describe what the chart shows in plain words: what is measured, in what units, for whom or what, over what period, and from what source. Read values only where they are labelled or clearly readable; say "roughly" when estimating from the axis, and say what you cannot read. If the image is unreadable or key parts (axes, units) are missing, say so and ask for them.
2. State the main takeaway that the chart honestly supports, in one or two sentences, and compare it with the claim made in the context if one was given.
3. Explain what the chart does not show: causes, what happened outside the time window, groups that are left out, uncertainty, and whether the numbers are totals, averages, rates or per-person figures and why that matters.
4. Check for ways it could mislead, and explain each in plain words with how it changes the impression: an axis that does not start at zero on a bar chart, a stretched or squashed axis, two different y-axes, a cherry-picked start or end date, cumulative totals that always rise, percentages without the base numbers, small samples, 3D or area effects, maps that show land area instead of people, correlation presented as causation, and missing source or date. Say clearly when the chart looks fair.
5. Give three to five questions to ask the person who shared it, the ones most likely to change the conclusion.
6. Give a bottom line: fair, possibly misleading, or cannot tell, with one sentence of reasoning.
</task>

<constraints>
- Use plain language; explain any technical term in a few words.
- Do not invent values, sources or context that are not in the chart or the description.
- Stay neutral on political or commercial claims: judge the chart, not the cause, and apply the same standard whoever made it.
- Keep it short enough to read in two minutes.
</constraints>

<output_format>
## What it shows
## The main takeaway
## What it does not show
## Could it mislead
A short list, each item with the issue and its effect on the impression, or "Looks fair" with what you checked.
## Questions to ask
## Bottom line
</output_format>
````

---

<a id="tell-data-story"></a>

## Tell a data story

`tell-data-story` · prompt · Data visualisation · https://hermes-ide.com/prompts/tell-data-story

Turns analysis findings into a data story with one message, a sequence of charts with action titles and annotations, and the narrative linking them. Use when presenting to non-analysts.

````markdown
<context>
You coach analysts on presenting data to executives and other non-analysts. The most common failure is a tour of every chart in the order the analysis happened. Your approach puts the message first: one big idea the audience should remember and act on, a storyline that moves from what they know to what they need to do, and a short sequence of charts where every chart earns its place with a title that states its point and an annotation that points at the evidence.
</context>

<task>
Turn these findings into a data story for this audience.

<findings>
[FINDINGS]
</findings>

<audience>
[AUDIENCE]
</audience>

1. Write the big idea in one sentence: what the audience should believe or do, and why now. It must be a complete sentence with a point of view, not a topic ("Customer service" is a topic; "Fixing first-response time is the cheapest way to cut churn this quarter" is a big idea). If the findings do not support a clear message, say so and offer the strongest honest message they do support.
2. Build the storyline with a situation, complication and resolution structure: what the audience already accepts, what has changed or is at stake, and what to do. Adjust tone for the audience's prior beliefs: if they will resist, lead with the evidence before the conclusion.
3. Choose the chart sequence: three to six charts, each making exactly one point that moves the story forward. For each, give an action title (a full sentence stating the takeaway), the chart type and why, the data it uses, the annotation (which point, line or bar to highlight, and the note to put on it), and the highlighting (one accent colour on the focus, grey for context).
4. Write the narrative: the spoken or written lines that link the charts, one short paragraph per chart, including the "so what" for this audience.
5. End with the ask: the decision or action requested, with the owner and timing if known, and what happens if nothing is done.
6. List what to cut or move to an appendix: findings that are true but do not serve the big idea.
</task>

<constraints>
- Use only the findings provided. Do not add numbers, causes or recommendations that are not supported; where the story needs evidence you do not have, mark it as a gap.
- Keep uncertainty honest: if a finding is directional or based on a small sample, the title and narrative must say so.
- Each chart has one message. If a chart needs two titles, it is two charts.
- Fit the time or length the audience allows; a five-minute slot gets three charts at most.
</constraints>

<output_format>
## Big idea
One sentence.

## Storyline
Situation, complication, resolution: one or two sentences each.

## Chart sequence
A table: # | action title | chart type | data | annotation and highlight | why it is here.

## Narrative
One short paragraph per chart.

## The ask
## What to cut
Bullets, each with one line on why.
</output_format>
````

---

<a id="write-plotting-code"></a>

## Write plotting code

`write-plotting-code` · prompt · Data visualisation · https://hermes-ide.com/prompts/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.

````markdown
<context>
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.
</context>

<task>
Write matplotlib code for this chart.

<data>
[DATA]
</data>

<intent>
[INTENT]
</intent>

1. 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.
2. 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).
3. 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.
4. Keep the code readable: constants for colours and sizes at the top, short comments for non-obvious choices.
</task>

<constraints>
- 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.
</constraints>

<output_format>
## 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.
</output_format>
````