# Data-visualization skills for coding agents: what they teach, and what the evidence supports Status: research snapshot, evidence cut 2026-08-14. Recheck by 2026-11-14, or earlier after a material change in model baselines, coding-agent harnesses, or the public skill registries. Companion: [The state of AI-assisted data visualization research](/reports/research-review/). This report examines reusable instruction packages that help coding agents such as Claude Code and Codex make data visualizations. It asks four questions: 1. What do the packages actually tell an agent to do? 2. Which techniques recur, and where do packages make meaningfully different choices? 3. Which instructions add durable value beyond a capable model and its normal harness, and which may be redundant or harmful? 4. What do public installation counts, repository activity, and the emerging research literature establish—and what do they not establish? The short answer is that the most valuable packages are not encyclopedias of chart advice. They encode facts a model is unlikely to infer reliably at run time: the local data and delivery contract, a version-specific API, a structured representation, known rendering failures, deterministic checks, and a repair loop over the artifact that will actually be delivered. Generic chart-selection and styling advice is common, but it is also the part most likely to overlap a modern model's baseline or impose context-free rules. ## Executive assessment The inspected packages fall into six different roles. Calling all of them “data-visualization skills” obscures what they do: | Role | What it contributes | Representative packages | | --- | --- | --- | | **Primer** | chart-selection heuristics, styling defaults, code examples | Anthropic Data Visualization; Owl Data Visualization | | **Narrative guide** | audience, message, sequence, annotation, call to action | Data Storytelling | | **Renderer gateway** | a narrow schema that produces an image or chart URL | AntV Chart Visualization; its vendored Deer Flow variant | | **Library or domain adapter** | version-specific syntax, runtime constraints, known failures, reusable examples | AntV G2; Mapbox patterns; Vega-Lite; scientific-visualization skills | | **Quality gate** | accessibility or screenshot-level visual critique | Data Visualization Accessibility; Critique Visual Hierarchy | | **Workflow and representation layer** | requirements, semantic fields, structured specifications, rendering, browser checks, iteration | Flint Chart; Vizro's dashboard flow; OpenAI's web-visualization skill family | These roles are complementary, not a ranking. A renderer gateway may be the right answer for a disposable preview and the wrong answer for an editable, auditable public chart. A scientific-visualization adapter can be highly useful in ParaView and irrelevant to a newsroom graphic. A visual-hierarchy critic can spot a weak focal point while missing a numerically false axis. The research supports five conclusions: - **Curated skills can materially improve agent performance, but the effect is conditional.** Across the broad SkillsBench evaluation, skills raised average pass rate from 33.9% to 50.5%, yet 13 of 87 tasks became worse. A separate software-engineering benchmark with an 89.8% no-skill baseline found only a 1.2-point average gain, and version-mismatched skills caused regressions. - **Specialized, fragmented knowledge is where skills have the clearest advantage.** A visualization-specific study found improvements across all ten tested scientific suite and agent combinations after adding version-pinned, tool-specific skills. General primers do not have comparable paired evidence. - **More instruction is not reliably better.** In SkillsBench, compact and standard skills produced larger gains than comprehensive ones; self-generated skills fell below the no-skill baseline on three model-harness configurations. - **Loading and routing are part of quality.** A useful package can still hurt when retrieved for the wrong task, loaded alongside distractors, or applied after its API assumptions have expired. Realistic retrieval experiments often underperformed an oracle that force-loaded the right skill and sometimes underperformed no skill at all. - **Popularity is a discovery signal, not effectiveness evidence.** Registry installations record acquisition, not use, retention, output quality, or reader outcomes. Repository stars usually belong to a large multi-skill or product repository and cannot be attributed to one visualization file. The practical direction is a compact common spine that identifies task, audience, data, claim, delivery surface, reading conditions, and state. It should then load the smallest relevant specialist: a library adapter, semantic chart representation, accessibility check, mobile delivery guide, or domain-specific validator. It should preserve the model and harness baseline where they are already competent and add instruction where the environment has specific facts or expensive failure modes. ## What an agent skill is An agent skill is a directory whose `SKILL.md` describes when a capability applies and how to perform it. It may also include reference files, scripts, templates, or assets. Compatible harnesses first read the name and description; they load the instructions and supporting material when a task matches. This “progressive disclosure” is intended to keep every possible manual out of the initial prompt. The [Claude Code documentation](https://code.claude.com/docs/en/skills) describes the format and loading model. That package boundary can hold very different things: - a prompt-like page of design advice; - an operational runbook for a particular library version; - a schema or intermediate representation for a chart; - executable validators and renderer calls; - an orchestrator that delegates to several narrower skills. The distinction matters because the likely value and risks differ. Advice is cheap to read but hard to verify. A versioned runbook can resolve obscure failures but go stale. A validator can make part of quality deterministic but only for the properties it checks. An orchestrator can cover a full workflow but consume attention, displace good model defaults, and force unnecessary steps on simple requests. ## What was inspected The scan began with the public skills leaderboard and focused registry searches for “data visualization,” “dataviz,” “chart visualization,” “data storytelling,” “visualization critique,” “D3 charts,” “Observable Plot,” “Vega-Lite,” and “scientific visualization.” Registry pages were treated as discovery and installation telemetry. Every package assessed below was then read from its current primary repository file. Repository metadata was captured separately. The deep-reading set contains 18 skill files or families across 13 repositories: - Anthropic Data Visualization - Wshobson Data Storytelling - AntV Chart Visualization and AntV G2 - the Deer Flow copy of AntV's chart renderer skill - Mapbox Data Visualization Patterns - Owl Data Visualization and Critique Visual Hierarchy - LangChain DeepAgents Data Visualization - Community Access Data Visualization Accessibility - a Claude-artifact Vega-Lite package - OpenAI's web-data-visualization router and strategy/critique specialist - Microsoft Flint Chart Author - Vizro's design, chart-selection, and build skills - SciVisAgentSkills for napari, ParaView, TTK, and VMD/MDAnalysis This is a purposive, not exhaustive sample. It covers the most visible registry results, several official or product-owned packages, distinct implementation styles, a narrow accessibility package, and the principal visualization-specific skill family with a published paired evaluation. The public marketplace alone contained 736 entries classified as data visualization in an early-February 2026 study, so a package count would communicate false completeness. ## Adoption signals: useful for discovery, weak for judgment The registry's documented `installs` field is a total deduplicated installation count. The table reports that number and repository-level GitHub stars as captured on 2026-08-14. A dash means a comparable registry page was not captured, not zero use. | Skill or family | Registry installs | Repository stars | Repository recency | What the numbers do **not** establish | | --- | ---: | ---: | --- | --- | | [Data Storytelling](https://skills.sh/wshobson/agents/data-storytelling) | 13,642 | 38,801 | pushed 2026-08-05 | that this file caused installs or improves charts | | [Anthropic Data Visualization](https://skills.sh/anthropics/knowledge-work-plugins/data-visualization) | 11,159 | 23,473 | pushed 2026-08-14 | usage, retention, or quality after installation | | [AntV Chart Visualization](https://skills.sh/antvis/chart-visualization-skills/chart-visualization) | 5,690 | 461 | pushed 2026-08-14 | correctness of generated values or chart choice | | [Deer Flow Chart Visualization](https://skills.sh/bytedance/deer-flow/chart-visualization) | 2,150 | 80,000 | pushed 2026-08-14 | skill-level popularity; the file credits AntV | | [Mapbox Data Visualization Patterns](https://skills.sh/mapbox/mapbox-agent-skills/mapbox-data-visualization-patterns) | 1,511 | 71 | pushed 2026-08-13 | production map quality or reader comprehension | | [Owl Data Visualization](https://skills.sh/owl-listener/designer-skills/data-visualization) | 1,257 | 2,075 | pushed 2026-08-08 | that its generic rules add to model baseline | | [AntV G2](https://skills.sh/antvis/chart-visualization-skills/antv-g2-chart) | 1,050 | 461 | pushed 2026-08-14 | performance outside G2 v5 tasks | | [Owl Visual Hierarchy Critique](https://skills.sh/owl-listener/designer-skills/critique-visual-hierarchy) | 746 | 2,075 | pushed 2026-08-08 | data correctness or effect on real readers | | [DeepAgents Data Visualization](https://skills.sh/langchain-ai/deepagents/data-visualization) | 262 | 27,763 | pushed 2026-08-14 | adoption of one example in a framework repo | | [Data Visualization Accessibility](https://skills.sh/community-access/accessibility-agents/data-visualization-accessibility) | 132 | 390 | pushed 2026-08-11 | conformance after browser and assistive-tech testing | | [Flint Chart Author](https://skills.sh/microsoft/flint-chart/flint-chart-author) | 64 | 3,765 | pushed 2026-08-14 | adoption of the new skill or comparative quality | | [Vega-Lite artifact skill](https://skills.sh/oaustegard/claude-skills/charting-vega-lite) | 57 | 137 | pushed 2026-08-12 | use beyond its particular artifact environment | | [OpenAI web-data-visualization skills](https://github.com/openai/plugins/tree/main/plugins/build-web-data-visualization) | — | 5,089 | pushed 2026-07-14 | skill-level use or paired effectiveness | | [Vizro dashboard flow](https://github.com/mckinsey/vizro/tree/main/vizro-e2e-flow) | — | 3,774 | pushed 2026-08-14 | skill adoption separate from the product | | [SciVisAgentSkills](https://github.com/KuangshiAi/SciVisAgentSkills) | — | 12 | pushed 2026-06-02 | registry adoption; its evidence comes from a benchmark | Three forms of ecosystem evidence explain why these numbers need restraint: 1. In a February 2026 snapshot of 40,285 marketplace listings, 46.3% shared a normalized name with another listing. Data-visualization entries averaged 2,322 tokens and 108 installs, but the paper explicitly treats installs as a coarse adoption proxy. ([Agent Skills ecosystem analysis](https://arxiv.org/abs/2602.08004)) 2. A July 2026 census found 3.8 million `SKILL.md` occurrences in 282,200 public GitHub repositories; 50.5% were verbatim copies. No central registry covered the full ecosystem. ([GitSkills](https://arxiv.org/abs/2608.10906)) 3. One registry page in this scan reported 3,513 installations for a `visualization-expert` skill, while the current linked repository no longer contained that `SKILL.md`. That does not prove the count is wrong; it shows that a registry record can outlive or drift from its source. Install counts can therefore prioritize reading. They should not select a package, justify binding it to an agent, or stand in for a no-skill comparison. ## Technique coverage The matrix uses three levels: **strong** means the technique is an explicit, substantial part of the package; **some** means it is mentioned or partially implemented; a dash means it was not found in the inspected files. “Structured representation” means an inspectable chart specification or semantic intermediate form rather than only generated plotting code. “Validation” means executable or browser-level checks, not a prose checklist. | Skill or family | Context and audience | Data inspection | Structured representation | Rendered visual review | Accessibility and mobile | Executable validation | Iteration or repair | | --- | --- | --- | --- | --- | --- | --- | --- | | Anthropic primer | some | some | — | — | some | — | some | | Data Storytelling | **strong** | — | — | — | — | — | some | | AntV image renderer | some | — | **strong** | — | — | some | — | | AntV G2 adapter | some | — | **strong** | — | — | some | some | | Mapbox patterns | some | some | some | — | some | — | some | | Owl visualization | some | some | — | — | **strong** | — | some | | Owl hierarchy critique | some | — | — | **strong** | some | — | some | | DeepAgents runtime recipe | — | — | — | some | — | some | some | | Accessibility audit | some | — | some | some | **strong** | some | some | | Vega-Lite artifact skill | **strong** | **strong** | **strong** | some | some | some | some | | OpenAI web visualization | **strong** | **strong** | **strong** | **strong** | **strong** | **strong** | **strong** | | Flint Chart | some | **strong** | **strong** | some | some | **strong** | **strong** | | Vizro dashboard flow | **strong** | **strong** | **strong** | **strong** | some | **strong** | **strong** | | SciVisAgentSkills | some | **strong** | some | **strong** | — | **strong** | **strong** | No row is universally best. The scientific packages deliberately optimize for headless technical rendering, not phone reading. The dashboard flow optimizes for a maintained application, not a one-off explanatory graphic. The accessibility package is a useful gate, not an authoring method. The matrix is a map of responsibility, not a scorecard. ## Deep reading: where each approach helps and hurts ### Primers and storytelling guides The [Anthropic Data Visualization skill](https://github.com/anthropics/knowledge-work-plugins/blob/main/data/skills/data-visualization/SKILL.md) is a broad handbook. It maps relationships to chart types, supplies Matplotlib, Seaborn, and Plotly patterns, and includes design and accessibility checks. It is a reasonable orientation for an unfamiliar user or a weak baseline model. It does not require a data profile, inspect a rendered artifact, run browser or mobile checks, or verify that values and transformations are correct. Rules such as “3D never” and “bar charts always start at zero” are safe defaults in many settings but become brittle when expressed without context or exceptions. The [Data Storytelling skill](https://github.com/wshobson/agents/blob/main/plugins/business-analytics/skills/data-storytelling/SKILL.md) frames a narrative through setup, conflict, resolution, a “so what,” and a call to action. It is strongest when a user already has a defensible analytical claim and needs to organize communication. It provides no chart construction, data-integrity check, uncertainty method, or rendering loop. Applied too early, its pressure toward a clean arc can turn exploration into a causal-sounding story before the evidence supports one. The [Owl visualization primer](https://github.com/Owl-Listener/designer-skills/blob/main/ui-design/skills/data-visualization/SKILL.md) is much shorter. Its uncommon value is explicit responsive guidance: simplify on mobile, provide a table alternative, and make interaction touch-friendly. “Test with real data” is directionally right, but the package does not specify how to test values, states, layout, or comprehension. Its chart and styling rules otherwise resemble model-baseline knowledge. **Assessment:** primers help most as short reminders or onboarding material. They should not be mistaken for a correctness layer. Their generic rules are also the most likely to be superseded as baseline models and harness guidance improve. ### Renderer gateways The [AntV Chart Visualization skill](https://github.com/antvis/chart-visualization-skills/blob/master/skills/chart-visualization/SKILL.md) turns data into a documented JSON payload, sends it to a chart service, and returns an image URL. Its value is speed and a stable schema covering many chart types. The [Deer Flow version](https://github.com/bytedance/deer-flow/blob/main/skills/public/chart-visualization/SKILL.md) explicitly credits AntV, wraps the same approach in a local generator, and returns the arguments as well as the image. This is a useful contract for previews, reports that only need a static image, or an agent that cannot build a local rendering stack. It is weaker when the data is sensitive, the output must remain editable, the reader needs accessible structure, or correctness requires inspecting transformations and chart state. The skills do not perform rendered critique, browser checks, mobile tests, or a value-level verification of the returned image. Their permissive catalog also includes chart forms—dual axes, radar charts, and pies—that demand contextual judgment rather than mechanical selection. **Assessment:** a renderer gateway is an execution convenience, not a full visualization method. Network and data-handling boundaries must be explicit. ### Library and domain adapters The [AntV G2 skill](https://github.com/antvis/chart-visualization-skills/blob/master/skills/antv-g2-chart/SKILL.md) targets a specific declarative grammar and version. It warns about critical G2 v5 pitfalls, retrieves documentation in progressive levels, and supplies a hybrid full-text/vector retrieval path. This is precisely the kind of hard-to-infer, version-sensitive knowledge that can save an agent from plausible but invalid code. It does not decide whether the result answers the reader's question. The [Mapbox patterns skill](https://github.com/mapbox/mapbox-agent-skills/blob/main/skills/mapbox-data-visualization-patterns/SKILL.md) covers choropleths, heatmaps, three-dimensional maps, animation, missing data, and performance thresholds for GeoJSON and vector tiles. It is a useful geospatial implementation guide. It says less about classification choices, normalization, projection, uncertainty, and map-specific misinterpretation. Those are analytical and reader risks, not just Mapbox syntax. The [Vega-Lite artifact skill](https://github.com/oaustegard/claude-skills/blob/main/charting-vega-lite/SKILL.md) profiles input data, derives chart candidates from question and context, and uses an inline data island to create a React/Vega-Lite explorer. Its inspection step and declarative output are stronger than a code-only primer. Its default request for five to ten charts can encourage dashboard-like overproduction; embedding all data inline may be inappropriate for large or sensitive inputs; and the workflow is tied to one artifact environment. The [DeepAgents example](https://github.com/langchain-ai/deepagents/blob/main/examples/nvidia_deep_agent/skills/data-visualization/SKILL.md) is narrower still: it shows how to render publication-style plots in a headless GPU sandbox using a noninteractive backend, save the file to an expected path, read it back, and close resources. That runtime bridge can be valuable inside its environment. It is not a general design or validation method. The four [SciVisAgentSkills](https://github.com/KuangshiAi/SciVisAgentSkills) pin tool versions and encode operational details for napari, ParaView, the Topology ToolKit, and VMD/MDAnalysis. They specify headless execution, data and array conventions, render-cycle workarounds, camera and color defaults, image capture, and a render–inspect–adjust loop. These are not generic charts; they are specialist manuals for scientific image, volume, topology, and molecular visualization. Their associated benchmark is discussed below. **Assessment:** adapters are the clearest durable role for skills. Their value comes from current, local facts. That also creates an expiry obligation: record the supported version, detect incompatibility, and provide a fallback. ### Quality gates The [Owl visual-hierarchy critic](https://github.com/Owl-Listener/designer-skills/blob/main/visual-critique/skills/critique-visual-hierarchy/SKILL.md) asks the agent to identify the entry point, eye flow, competing visual weight, and emphasis, then return observations, problems, fixes, and a severity verdict. This structure can make screenshot critique actionable. Its hard ratios and generalized F- and Z-pattern advice are not a substitute for testing this audience and composition. It also does not inspect data semantics, axes, transforms, or numeric claims. The [Data Visualization Accessibility skill](https://github.com/Community-Access/accessibility-agents/blob/main/codex-skills/data-visualization-accessibility/SKILL.md) checks SVG labeling, descriptions or table alternatives, contrast, keyboard access, screen-reader behavior, 400% zoom, responsive layout, and touch targets. It is a useful narrow gate because these requirements are frequently omitted elsewhere. At 21 lines, it cannot determine conformance by itself; some ARIA choices are context-dependent and require browser and assistive-technology testing. **Assessment:** critique should be decomposed. Visual hierarchy, data/transform correctness, accessibility, interaction, responsive layout, and reader comprehension are different checks. A general vision model looking at a screenshot cannot recover all of them. ### Structured workflow packages The [Flint Chart Author skill](https://github.com/microsoft/flint-chart/blob/main/agent-skills/flint-chart-author/SKILL.md) uses a semantic chart input with typed fields, separates the chart specification from rendering backends, and requires transforms before chart construction. It asks the agent to sanity-read values and totals, validate the specification, render or compile through tools, and use a manual escape hatch only after a valid spec exists. This is one of the strongest approaches for inspectability and deterministic checking. It does not by itself establish browser, mobile, accessibility, or reader performance. The [Vizro flow](https://github.com/mckinsey/vizro/tree/main/vizro-e2e-flow) splits dashboard work into requirements and layout, chart selection, and build. It creates separate specifications, makes interactions explicit as source–control–target relationships, validates aggregation and colors, runs code and terminal checks, walks the browser, activates every action, inspects console/network/server output, and compares screenshots. This is an unusually complete delivery loop. Its completeness can also become a liability. Mandatory multi-document design and approval steps are disproportionate for simple work. “Always copy an example,” default KPI counts, automatic dependency installation, and blanket chart bans may conflict with the project, environment, or user's authority. The package is strongest when a maintained Vizro dashboard is actually the job. The [OpenAI web-data-visualization family](https://github.com/openai/plugins/tree/main/plugins/build-web-data-visualization) starts with task, data, delivery surface, reading path, and state; routes work to the smallest specialist; treats mobile and accessibility as first-class; and requires contracts, fallbacks, browser quality assurance, and renderer fit. Its strategy specialist distinguishes editorial, operational, and sensitive contexts and treats a large composition and a mobile composition as related but not identical. Among the packages inspected, it covers the broadest set of reader and delivery concerns. That breadth carries orchestration cost. The family is large, can force concept generation or user pauses when a simpler continuation would work, and has no public visualization-specific paired evaluation. Its best ideas are likely to survive as a compact routing and acceptance contract; loading the entire family for every chart is not yet justified. **Assessment:** structured representations and executable acceptance checks are more defensible than longer prose. End-to-end workflows should be invoked by task complexity and delivery risk rather than treated as the default. ## What has actually been measured ### Direct visualization evidence The 2026 [SciVisAgentSkills study](https://arxiv.org/abs/2606.05525) is the clearest direct test in this corpus. It constructed 108 expert-designed, multi-step tasks across ParaView, molecular visualization, bioimage analysis, topological visualization, and object visualization. Claude Code with Sonnet 4.5 and Codex with GPT-5.2 each ran three trials with and without the tool-specific skills. Scores improved in all ten suite–agent comparisons. Examples include Codex on molecular visualization, 62.30 to 73.13; Codex on bioimage tasks, 41.90 to 55.00; Claude Code on topology, 45.23 to 73.63; and Claude Code on object visualization, 41.50 to 69.13. The largest gains occurred where APIs were specialized and fragmented. Gains were smaller in the mature, better-known VMD environment. Completion did not improve uniformly: Codex object-visualization completion fell from 92.59% to 80.25% even as its quality score rose from 43.33 to 47.77. This is measured evidence, not a universal effect. The authors built and tested their own skills; evaluation mixed deterministic image metrics, code and rule checks, and multimodal-model judging; and no independent reproduction was found. The tasks are scientific, not ordinary business charts or explanatory mobile graphics. ### General skill evidence that bears on visualization The broader literature explains which package properties deserve experiments: - [SkillsBench](https://arxiv.org/abs/2602.12670) evaluated 87 tasks across eight domains and 18 model-harness configurations. Average pass rate rose from 33.9% without skills to 50.5% with skills. All configurations improved in aggregate, but 13 tasks regressed. One skill produced an 18-point gain, two or three produced 19 points, and four or more produced 10.1 points. Compact and standard packages gained 19 and 21.5 points; detailed packages gained 14.5; comprehensive packages gained only 0.7. Self-generated skills fell below the no-skill baseline on three tested configurations. - [SWE-Skills-Bench](https://arxiv.org/abs/2603.15401) tested 49 public skills on 565 repository tasks. Its no-skill baseline was already 89.8%, and skills raised it to 91.0%. Thirty-nine of 49 skills produced no change; seven helped meaningfully; three hurt, by as much as ten points, because their guidance did not match the repository's version or environment. Even unchanged results could add token cost. - A [realistic skill-retrieval study](https://arxiv.org/abs/2604.04323) assembled 34,198 permissively licensed packages and found that automatic retrieval was materially worse than force-loading the curated skill. On SkillsBench with Claude, force-loaded skills reached 55.4%, while automatically retrieved skills that included the curated package reached 40.1%; no skill reached 35.4%. For other tested models, realistic retrieval could fall below the no-skill baseline. Query-specific refinement improved results only when the initial retrieved material was relevant and good. - A [registry-to-repository study](https://arxiv.org/abs/2607.00911) found that only 33% of central skills contained verification or evaluation guidance and 23% included state inspection. About half included failure recovery. When developers adapted central skills locally, changes usually bound them to an environment rather than rewriting their stable behavioral contract. The general benchmarks are not evidence that any named visualization package works. They are evidence against three tempting assumptions: that any skill is better than none, that more detailed instruction is safer, and that finding the right package can be separated from testing its effect in the actual harness. ## Where the field is converging Across package design and benchmark evidence, six patterns look durable: 1. **Start with a use contract, not a chart type.** Task, audience, analytical claim, data, stakes, delivery surface, reading conditions, and existing state determine what “good” means. 2. **Keep execution state inspectable.** A semantic chart object, declarative grammar, explicit transform, or visible intermediate table is easier to validate and repair than an opaque image. 3. **Use progressive specialization.** Load version and domain knowledge only when it applies. One compact router plus small specialists is better supported than a universal manual. 4. **Render and inspect the delivered surface.** Code completion is not chart completion. Browser state, mobile composition, interaction, missing data, and exported files can fail after the specification is valid. 5. **Make cheap properties deterministic.** Schema validity, field types, totals, aggregation, axis configuration, console errors, interaction states, contrast, and artifact persistence should not depend entirely on prose or visual judgment. 6. **Provide repair and fallback paths.** A skill should detect version or environment mismatch, stop before destructive improvisation, and return to a simpler supported representation. ## Where approaches still diverge The divergences are real because visualization contexts differ: - **Exploration versus explanation.** An exploratory workflow benefits from cheap branching and multiple views. A published graphic benefits from a deliberate claim, restrained composition, and reader testing. A fixed quota of five to ten charts may help the former and clutter the latter. - **Image output versus editable state.** A URL-returning renderer is efficient for a preview. Semantic or declarative output is safer when people must audit, revise, localize, update, or make the chart accessible. - **Dashboard operation versus editorial storytelling.** Dashboard packages emphasize metrics, controls, states, and recurring delivery. Storytelling packages emphasize sequence and rhetorical focus. Neither should silently replace the other. - **General charts versus specialist scientific or geospatial work.** The latter often depends on array conventions, file formats, camera and rendering state, scientific semantics, or projection and classification choices that a generic chart guide cannot cover. - **Aesthetic critique versus semantic critique.** Screenshot hierarchy is visible to a vision model. Hidden transforms, provenance, missingness, and whether the chart answers the question require data and intent. - **Guidance versus executable control.** Some authors prefer broad natural- language freedom; others constrain the model through schemas, compilers, and validators. The appropriate balance depends on how costly an invalid or unmaintainable output would be. These are delegation boundaries for a shared spine, not disagreements that one universal skill needs to settle. ## What can hurt Several failure patterns should be treated as explicit tests rather than style preferences. ### Demonstrated in broader skill benchmarks - stale or version-mismatched instructions can reduce task performance; - comprehensive skills can displace better model or harness behavior while adding attention cost; - self-generated skills can perform below no skill; - irrelevant retrieval and distractor skills can erase much of a curated package's gain; - token use can rise even when correctness does not change. ### Found in the inspected visualization packages, but not yet quantified - context-free absolutes and magic numbers presented as universal design law; - chart quotas or KPI counts that encourage decorative dashboard production; - a narrative arc applied before data and uncertainty support the story; - screenshot critique treated as evidence of numeric or analytical correctness; - external rendering services used without an explicit data-handling contract; - full datasets embedded inline without privacy and scale checks; - complex specifications and approval steps forced onto low-risk, one-off work; - automatic installation of dependencies or other environment changes beyond the user's request; - accessibility represented by an ARIA checklist without browser, keyboard, zoom, contrast, and assistive-technology testing; - mobile treated as shrinking a desktop composition rather than a distinct reading path; - registry installs or parent-repository stars reported as if they were a behavioral evaluation of one file. ## Recommended experiment sequence Do not start by choosing the most popular package. Compare interventions in the same model, harness, task, and environment: 1. **Establish the current baseline.** Run representative tasks with the model's normal harness and no added visualization skill. Preserve prompts, outputs, time, tokens, repair attempts, and final artifacts. 2. **Add only the common use contract.** Require task, audience, claim, data, stakes, delivery surface, reading conditions, and state. Measure whether this changes correctness or merely adds ceremony. 3. **Add a narrow specialist where knowledge is hard to infer.** Test a pinned library adapter, domain manual, accessibility gate, mobile delivery guide, or renderer contract only on applicable tasks. 4. **Introduce an inspectable representation and deterministic checks.** Compare free-form code with a semantic or declarative chart specification. Validate data transformations, fields, values, and supported interactions before visual review. 5. **Add render and delivery checks.** Inspect the actual browser or exported artifact at desktop and mobile sizes; exercise states; check accessibility, console and network failures, and persistence. 6. **Test routing under realistic noise.** Only after specialists work when explicitly selected should retrieval choose among them. Include irrelevant packages and a no-skill fallback. 7. **Test an end-to-end workflow last.** Compare its additional quality with time, token, latency, user interruption, and maintenance cost. Keep it only for contexts where the gain exceeds the ceremony. The task set should deliberately span different meanings of visualization: exploratory analysis, operational BI, explanatory or journalistic graphics, geospatial work, scientific visualization, and mobile reading. Score at least: - data and transformation correctness; - whether the visualization answers the stated question; - chart and encoding appropriateness in context; - editability, inspectability, and correction cost; - delivery success and interaction-state coverage; - accessibility and mobile readability; - human time, model tokens, latency, and number of repair turns; - reader comprehension and calibrated trust for published artifacts. This sequence is designed to discover the smallest useful scaffold. The likely future is not no skills, and it is not a permanent encyclopedia around every model. It is a thinner orchestration contract around improving baselines, with maintained specialists for local APIs, semantic representations, deterministic verification, and expensive contextual failures. ## Evidence limits and open questions This report can compare written instructions, public acquisition signals, repository activity, and published benchmarks. It cannot establish routine field use, private enterprise adoption, retention, creator satisfaction, or reader outcomes for the named packages. The most important missing evidence is visualization-specific and paired: - the same current model and harness with and without each package; - controlled comparisons between a generic primer, a narrow specialist, and a structured workflow; - context-stratified tasks rather than one blended chart score; - independent tests of mobile, accessibility, correction cost, and reader comprehension; - maintenance studies that measure regressions as models, libraries, and harnesses improve; - provenance-aware registry analytics that collapse copied and vendored skills before comparing adoption. Until those exist, the responsible conclusion is conditional: visualization skills can help substantially when they supply relevant, current, hard-to-infer knowledge and verifiable execution structure. Their existence, detail, install count, or parent repository popularity is not evidence that they improve a given agent in a given environment. ## Update log - **2026-08-14 — Initial public edition.** Cataloged agent skill packages, adoption signals, recurring techniques, evaluation evidence, likely failure modes, and an ordered ablation program.