snappy-chart

The chart skill - purpose TBD.

One paragraph: what this skill does, why it exists, and what failure mode it prevents. If you can't name a failure mode, the skill probably doesn't need to exist - leave it out. Replace this paragraph as soon as the first agent runs the skill and discovers the real shape.

Observed user requests

These are the prompts that triggered this skill being scaffolded:

• "make that chart better with trend arrows for each skill"
• "now make that chart better - show it as a grouped bar chart with trend arrows for each skill"
• "show me a bar chart with three data points: A=10, B=25, C=15"

The Steps section below is a first-draft response to this cluster - refine as eval scores accumulate.

Steps

1. Parse request

Extract the data and chart type from the prompt. Support bar, line, area, pie, and radar charts. Normalize data shape to {labels, datasets}.

2. Compose OpenUI Lang

Compose the chart through compose_inline by default, or direct Lang when the exact OpenUI body matters. Use OpenUI primitive chart composition (BarChart, LineChart, PieChart, etc. from the genui-library). Do not emit [[TOOL:Lang]] markers.

Chart signatures are not object-row APIs:

labels = ["A", "B", "C"]
values = [10, 25, 15]
series = [Series("Data", values)]
bar = BarChart(labels, series, "grouped")
pie = PieChart(labels, values, "donut")

Do not pass [{label: "A", value: 10}] directly to BarChart or PieChart. That renders as object placeholders and bad percentages in the cockpit.

3. Render in cockpit

The chart appears inline in snappy-os as a generative-UI card via the Lang renderer in dispatch-card.tsx.

4. Score

score("snappy-chart", run_id, {
  score: valid_chart ? 1.0 : 0.0,
  primary_issue: valid_chart ? null : "invalid-data-shape",
});

Eval

Actor: the thing that produces the output (a dispatch model, a CLI, or the state/lib/snappy-chart.ts library if one exists). Auditor: the thing that judges (must be different - see CONSTITUTION invariant #3). Name both explicitly.

Score convention:

If you cannot name a deterministic auditor, switch the frontmatter to eval: manual and log to state/log/pending-eval.ndjson - but fight to avoid manual. Manual is the escape hatch that leaks the thesis.

Gotchas

• List concrete failure modes you hit while building. Examples: "API

returns 200 with empty body"; "round-tripped text has a , artifact where em-dashes used to be"; "cache file is stale after 12h."

• If a gotcha matches an entry in user memory (see ~/.claude/CLAUDE.md),

cite the memory name so future agents can follow the trail.

snappy-chart - loader

Per-turn rules for snappy-chart. Full reference: state/skills/snappy-chart/SKILL.md.

Critical Rules

1. Compose charts through the current live-surface contract. Default to

compose_inline. Use direct Lang only when you must hand-author the exact OpenUI body. Never emit [[TOOL:Lang]] markers.

1. Ground the data first. Do not draw a chart until the numbers are real.

Use actual tool results or normalized input from the turn. No fabricated labels, counts, or trend claims.

1. Normalize chart input. Convert source data into a consistent shape the

chart can reason about before composing. If the data is malformed or too ambiguous to chart honestly, say so and ask for the missing structure.

1. Use OpenUI chart signatures exactly. BarChart, LineChart, and

AreaChart take labels plus [Series(name, values)]. PieChart takes labels plus values. Never pass {label, value} object rows directly to chart components.

1. Comparison must read instantly. The surface should make the pattern

obvious at a glance: what is up, what is down, what matters, and what the user should inspect next.

1. Trend indicators should use standard Lang primitives. Use tags,

callouts, labels, tables, or supporting rows where needed. Do not invent custom SVG or TSX for a normal chart explanation.

1. Scope-only by default. Render the chart as a preview or structured

answer unless the user explicitly asked to persist, schedule, or publish something from it.

1. Refinement means improve the same charting surface. For prompts like

"better", "again", or "make this clearer", preserve the underlying data and improve hierarchy, fidelity, comparison, labeling, or supporting context instead of swapping to an unrelated generic card.

1. Durability uses artifacts, not ui.openui. If a chart view becomes a

reusable live app, it persists via artifact lang_body and reopens via OpenArtifact.

Commands

Self-Test

• [ ] I will use compose_inline by default, not marker emission.
• [ ] I will ground the numbers before charting them.
• [ ] I will use flat arrays and Series(...), never object rows in charts.
• [ ] I will improve the existing chart on refinement turns instead of falling back to a generic recap card.
• [ ] I will not reference resources/ui.openui or a file-backed chart surface.
• [ ] I will use standard OpenUI primitives for comparison and trend cues.

Found a gap? Edit this file. <!-- footer-injection-point -->