---
name: create-dashboard
title: Create Dashboard
description: Author and revise a substantial interactive dashboard in the side panel using existing A2UI components, composed layouts, shared data bindings and linked views.
---

Use this skill when the person wants a dashboard or consolidated interactive
report. Author an interconnected presentation of substantial data, with a clear
overview and useful detail. The dashboard is an artifact alongside chat, with
the existing A2UI semantics throughout. Develop it over as many tool calls as
useful; a dashboard is not limited to one or two graphs or one generation call.

Inspect relevant earlier views with `inspect_a2ui_surface` and read their
referenced data. Decide what tells the story: retain meaningful comparisons,
remove repetition, add explanations, and generate new evidence-based figures
when useful. For example, show an original shape once with two chosen evolutions.
Keep units, source identity, and limitations clear. Do not invent measurements
or imply that a derived visual was part of the original recording.

Before authoring, identify the reader's question and supported finding. Decide
the role of each panel, shared colour meanings, useful annotations and the
initial level of detail. Load `references/report-design.md` for worked layouts
using this catalog. Prefer a few complementary views over repeated views of
the same data. Choose a custom guarded chart when it explains the finding
better than a preset; a technically fitting preset is not a design requirement.
For a complete small example, load `references/bike-station-report.json` and
`references/bike-stations.csv`. They connect one clearly synthetic dataset to
an annotated time chart, station balance, map and exact source table. Adapt the
composition to the person's evidence; never reuse the fictional measurements
as real findings. Preserve the same category labels across related maps and
nominal chart encodings so the shared automatic colours keep their meaning.

Load the active catalog index and exact component schemas with `load_skill`.
The catalog remains the authority for shapes and actions. Reuse its rows,
columns, frames, grids, text, metrics, charts, tables, meshes, images and inputs.
Default to one composed report: keep related evidence visible together so a
person can compare it without switching tabs, and a PNG tells the same story.
Use tabs for genuinely separate workflows or optional depth, not to separate
a chart from the map, image or comparison needed to interpret it. Keep the
main finding and its supporting views in the initial space. Do not ask
the person to supply component payloads.

Use the declared `review-visual-presentation` skill to close the loop on
substantial reports. Bind `Tabs.activeTab` when agent review needs to select tabs.
Use `inspect_a2ui_surface` and `capture_a2ui_surface` for the overview and each
relevant tab, revise what is unclear, and capture the correction. Capture a
published version with its exact `artifact_id`; keep revisions immutable.
Check the docked view as well as an expanded one. Surface acceptance alone
does not establish readable pixels; state when rendered inspection is unavailable.
Review the explanation as well as geometry: is the finding apparent, does every
panel earn its space, and do labels, colour meanings, units and filters agree?
Choose a useful default rather than showing every graph or series at once.
Retain the source data and let people reveal useful detail through supported
tabs, filters, selectors or optional-view controls. Do not invent visibility
properties or make hidden content the only place the answer can be found.
Annotations and linked selections can connect an explanation or question to
specific evidence; they do not replace the question's explicit answer action.

Choose the layout that fits the content. A single full-width diagram, equal
columns, a simple vertical report and uneven columns are all valid. Give wide
workflows and dense diagrams enough width to keep their labels readable. Use
unequal `Row` child `weight` values when one view needs more space, and `Grid`
for equal comparisons. These are options, not a template to reproduce. Weights
are relative shares, not grid spans. Put related evidence and its controls
together. Review the actual docked and expanded layouts before deciding whether
to stack panels, change proportions or use separate views. Dividers, lists, images, icons, and modals
remain available when they serve the presentation; do not add them solely to
exercise the catalog.

Write an editable JSON document inside the workspace:

```json
{
  "format": "clio.dashboard.document.v1",
  "title": "Design evolution",
  "catalog_id": "ACTIVE_CATALOG_ID",
  "source_surface_ids": ["earlier-comparison"],
  "components": [
    {"id": "root", "component": "Column", "children": ["summary", "analysis"]},
    {"id": "summary", "component": "Text", "text": "An evidence-based summary."},
    {"id": "analysis", "component": "Text", "text": "Replace this with your composed linked data views."}
  ],
  "data_model": {}
}
```

There must be one `root` component. The whole dashboard shares one ordinary
A2UI data model, so related controls and views can bind to the same paths.
Use the catalog's existing selection and query/filter contracts. Linked datasets
need a real shared entity field; matching row numbers in unrelated datasets
does not establish a relationship. Mesh views with a deliberately shared
`syncGroup` rotate and zoom together, including views authored from results
produced hours apart. Choose these links based on what the comparison means.

Reference full registered source data rather than sampling it to fit the report.
Small inline tables remain allowed by the catalog. Generate additional images
or charts through real analysis and normal artifact registration. Keep a
derivation distinct from observed evidence. Do not repeat the dashboard's views
inline in chat.

Call `publish_dashboard_report(definition_path="reports/design.dashboard.document.json")`
to validate and publish an immutable artifact version. Return its artifact
reference so the person can open the dashboard in the side panel. Keep the
returned report id and source path. For follow-ups, inspect the referenced
artifact version, edit the source through additional tool calls, and publish
again with `report_id`. Earlier artifact versions remain available. Add, remove,
rearrange, annotate, or interconnect content as the person's goals require.
Use the returned `report_id` for revisions; an owned dashboard artifact reference
also resolves the report family. Saved inspection returns these identities under
`artifact`. A newly published report opens in the currently viewed conversation
for review. Inspect its fresh viewer before capturing; a disconnected client or
different conversation still cannot supply pixels.

Review the published artifact's own viewer, including each tab. Inspect with
`artifact_id`, then navigate declared local bindings using
`update_a2ui_data_model` with that artifact id, the inspected surface revision,
viewer id and `expected_view_revision`. Capture the changed view and inspect
its pixels. Each update targets one exact path listed in the inspection's
`controls`; replacing their parent object is not a supported control update.
Reinspect after a change to obtain the new viewer epoch before changing another
control. Local navigation preserves the saved artifact version; changing
its authored contents requires editing the source and publishing a new version.

The viewer supplies standard Reference this and labelled image capture actions
for the dashboard and its individual views. References identify the artifact
and source document as well as the selected component or data zone. These let
the person ask you to revise part of the system or produce a new derived visual.
PNG downloads capture the displayed dashboard; self-contained HTML includes the
entire dashboard, its tabs and interactions, and referenced data. Missing
dependencies are reported rather than silently omitted from an export.

Present the completed dashboard once in the final response. Keep corrected
versions in the same report family; earlier versions remain in Versions and
Observability. Review captures are retained verification evidence.

Register the editable source as an intermediate only if a separate artifact is useful;
the published report already retains its source path. Do not add a second
deliverable card for that document unless the person requests the source file.
Register other review files with `create_artifact(..., purpose="verification")` and
working files with `purpose="intermediate"`; omit them from the final answer
unless requested. A requested image/PDF/HTML export is a deliverable and uses
`purpose="deliverable"`.