v1-reviewing-data-graphics

name: v1-reviewing-data-graphics description: Use when reviewing charts, dashboards, quantitative graphics, data visualizations, metric screenshots, or visual reports. Triggers on "review this chart", "audit this dashboard", "is this visualization misleading", "critique this data display", "review these metrics". allowed-tools: - Bash - Read - Grep - Glob

Reviewing Data Graphics

Review charts, dashboards, and quantitative displays for truth, evidence, comparison, and clarity.

Default mode is review-only. Recommend redesigns, but do not edit source files unless the user explicitly asks for implementation.

Quick Start

For a chart, dashboard, screenshot, HTML report, or component:

1. Identify the question the display claims to answer.
2. Inspect the actual visual surface when available; do not review only source code, OCR, alt text, or data tables when the rendered graphic is available.
3. Check integrity before taste: proportional representation, context, labels, units, comparison baselines, and omitted data.
4. Check whether the display helps the viewer reason about the data: comparisons, detail levels, density, direct labels, and integration with surrounding text.
5. Return findings first, ordered by severity, with concrete redesigns and validation checks.

What To Review

Review every visible quantitative element:

• Charts, maps, sparklines, scorecards, tables, gauges, funnels, timelines, and cohort views.
• Legends, labels, axes, gridlines, annotations, units, colors, and text around the graphic.
• Empty/loading/error states if the display is generated by an app.
• Data source notes, filtering controls, date ranges, denominators, and aggregation labels.

If the display is not visible, first try to render or open it. If rendering is blocked, say exactly what was reviewed instead.

Review Workflow

1. Establish The Graphic's Job

Extract or infer:

If the display has no clear job, mark that as a finding before discussing style.

2. Integrity Pass

Read and apply the canonical visual evidence checklist, especially its integrity, comparison, data-ink, density, labeling, interaction, and validation sections.

Keep this skill focused on the data-graphics review: identify the display's job, inspect the visual surface, map checklist failures to severity, and propose redesigns tied to the viewer's decision. Do not maintain a parallel copy of the checklist here.

3. Classify Findings

For each actionable issue, classify:

• The viewer decision or claim at risk.
• The checklist category involved.
• The evidence visible on the rendered display.
• The likely misleading conclusion or interpretation cost.
• The smallest redesign that fixes the decision problem.

Avoid generic advice such as "make it cleaner" or "use better colors." Tie every redesign to the claim, data, or viewer task.

Output Format

Use this structure unless the user asks for a different format:

## Findings

[Severity] Surface - Short title
Problem: What the display gets wrong.
Impact: How it can mislead or slow the viewer.
Fix: Concrete redesign.
Validation: How to verify the redesign works.
Confidence: N/5.

## What Works

- Useful strengths worth preserving.

## Redesign Sketch

- Minimal sequence of changes.

## Data Gaps

- Missing source data, unavailable rendering, unreadable labels, or assumptions.

Severity model:

• Critical: likely to cause a materially false conclusion.
• High: hides essential context, scale, denominator, or comparison.
• Medium: meaningfully slows interpretation or buries the main comparison.
• Low: polish issue with a clear readability benefit.

If no findings are found, say so and list the residual risks, such as unavailable data source, uninspected responsive state, or missing source notes.

Review Checks

Before finalizing, ask:

• What conclusion would a rushed viewer take away?
• What comparison is required to believe that conclusion?
• What visual encodings are not carrying data?
• What data is missing because it would weaken or complicate the claim?
• Would a table, small multiples, direct labels, or annotations make the display more truthful?
• Did the review inspect the rendered display, not just the implementation?

Chaining

• Use v1-html-it when the user asks to implement or package a self-contained visual artifact after the review.
• Use v1-reviewing-usability when the main risk is interaction, task completion, state visibility, or recovery rather than quantitative representation.
• Use v1-prd when the review reveals requirements, data contracts, states, or validation criteria that must be specified.

When Not To Use This Skill

• Do not use for general UI reviews without a quantitative display; use v1-reviewing-usability.
• Do not use for creating a polished HTML artifact from scratch; use v1-html-it.
• Do not use for broad product strategy or market evidence; use v1-strategy-review or v1-learning-from-customers.

Examples

Misleading metric card

Finding: A revenue card shows +42% without baseline, date range, denominator, or absolute revenue.

Fix: Show current value, comparison period, prior value, date range, and whether the percentage is nominal, real, gross, or net.

Overdecorated bar chart

Finding: A 3D bar chart uses perspective and shadows that make similar values look materially different.

Fix: Use a flat bar chart or dot plot with direct labels and a scale that matches the decision being made.

Dense but useful report

Finding: A table-chart hybrid contains many values but supports clear scanning by row and column.

Fix: Preserve density; improve row grouping, units, and annotations instead of splitting it into many sparse cards.