---
name: review-visual-presentation
title: Review figures and layouts
description: Inspect, control, capture and refine complex data views before presenting them. Review matching pixels at the user's viewing size; preserve coherent composition, linked evidence and consistent meanings. Use during visual investigation or for substantial dashboards.
---

Use visual interaction to investigate a question and to improve what a person
will see. The loop is: inspect the evidence and current view, change a declared
control or component, inspect the resulting image, reason, and refine.
Choose changes that resolve a concrete uncertainty or presentation problem.
This applies to maps, charts, tables, images, models and interconnected reports.

For a substantial authored dashboard or diagram, close this concrete loop:

1. Open the actual published viewer, inspect its current capture target, and
   capture the overview at the width the person will use.
2. Look at the returned image, not just its URI, source JSON or tool success.
   Check whether the main idea is apparent, text is readable, the whole diagram
   fits, and empty space or narrow columns obscure relationships. Ask whether
   a full-width view, equal panels or a simpler arrangement would explain it better.
   Include the surrounding frame/component headings, not only the plotted marks:
   a title cut off with an ellipsis is a defect even when the graph fits. Check
   whether labels can actually be read at this size, rather than merely seen.
3. Identify a concrete defect and change the source or a declared view control.
   Changing column counts is useful only when it fixes the observed problem.
4. Capture the revised view and inspect its image to confirm the correction.
   Check an expanded view as well when the docked and expanded arrangements differ.
5. Exercise important declared controls or linked selections. For a workflow
   folder link, verify the target with filesystem tools. If interaction tools are
   available, check that clicking selects that folder in Files. Claim a navigation
   check only when it was observed; a highlighted box alone does not prove it.

Repeat while a material defect remains. State the actual visual checks and any
unresolved limitation. Schema validation, a capture receipt and an uninspected
image do not establish visual quality. A small inline diagram does not require
building a dashboard or following an elaborate layout recipe.
Keep docked and expanded findings separate: readability in an expanded image
does not establish readability in a narrow pane. When text remains too small,
revise the view or state that limitation instead of declaring the review clear.

Read the current surface with `inspect_a2ui_surface` and load the relevant
active catalog schemas. `update_a2ui_components` replaces complete definitions
for the named components; preserve the other properties, references and links.
`update_a2ui_data_model` changes a declared binding. Reuse shared filter and
selection semantics rather than inventing another interaction model. For definition
changes to saved dashboards, edit the source document and publish a new immutable version.

Distinguish server state from a rendered view. A producer's `rendered=true`
means the definition was accepted, not that you inspected its pixels.
`inspect_a2ui_surface` reports fresh mounted viewers, declared bindings,
current values, cameras, active tabs, data references and readiness. Choose
the viewer you mean when several are open. `capture_targets` supplies the exact
capture arguments for each visible matching viewer; use the chosen target
without adding a guessed view epoch. Pass the inspected revision to
updates, then capture the new revision with `capture_a2ui_surface`. Its result
attaches real pixels to your next model step and retains a hashed image artifact
with the viewer state. For a saved dashboard, pass its immutable `artifact_id`
to inspection and capture. Review a temporary live surface when you need to
change a saved definition; publish the reviewed document as a new version.
To navigate or change declared controls in an open saved dashboard, use
`update_a2ui_data_model` with its `artifact_id`, surface/revision, selected
`viewer_id` and inspected `expected_view_revision`. This changes only that
view's local binding. Inspect its acknowledgement and capture the new epoch;
it does not edit the immutable artifact or submit a question answer.
Bind `Tabs.activeTab` to review each tab; its value is a tab child id.
Bind `clio.map.v1.camera` to pan, zoom or rotate a map, sharing the path when
views should move together. Keep reference-backed queries and selections
authoritative. An image URI, export link or unrelated earlier screenshot is
not visual inspection. Verify the capture's revision and state before reasoning.
Use the inspected component's exact binding path; map and mesh cameras can
have different paths and shapes in the same dashboard. Change that binding
instead of replacing the root data model with a guessed set of properties.
Compare the actual captured camera, frame and filters with the requested
values. If a declared control did not move, inspect its binding and correct
the update, then capture again before claiming the change worked.
For multiple tabs or camera positions, compare each returned capture's control
values and view revision with the requested view. Keep the image hash with that
state. Repeated tool arguments or an earlier screenshot are not evidence of a
new view; confirm the returned pixels and state before counting it as reviewed.
If a viewer is still loading, pass `expected_view_revision=null` (or omit it)
to let capture wait for readiness within its deadline. Pin a view epoch
when an already-ready human view must match exactly; a loading epoch
intentionally becomes stale as tiles or layout finish.
After publication, the newly opened viewer can still be mounting. A single
`a2ui_view_stale` or `a2ui_render_not_ready` result is not the end of the review:
inspect the same immutable artifact again and retry capture with its current
viewer. If `ready` is false, pass `expected_view_revision=null` rather than guessing
zero. Retry at most twice for each requested view; stop and report the actual limitation if the viewer
is absent or still cannot supply pixels. After each successful declared tab or
camera change, use the acknowledged epoch or inspect afresh before capture.
If capture or a requested control is unavailable, make supported structural
corrections and state the remaining verification limit; do not fabricate a
capture or describe a map camera as controllable because the person can zoom it.

Inspect at the size the person will use. Check the overview, relevant tabs,
labels, legends, units, contrast, clipping, framing and controls. Ask whether
the view answers the question and is valuable to a human: can the reader find
the important comparison without deciphering a dense wall of marks?
Also review the explanation: what conclusion can a person see in this image,
which marks support it, and what uncertainty remains? Compare related panels'
category meanings, ranges, dates and selected records. Use direct labels or
reference marks where they reduce the effort of finding the evidence. Remove
redundant panels and give the central comparison more space. Load the dashboard
skill's `references/report-design.md` when composing a substantial report.
Check composition as a whole: can related charts, images, viewports and text
be interpreted together without tab switching? Review a whole-report image,
not only individual views. Preserve unequal row proportions when expanded
and readable stacking when docked. Optional tabs must not hide essential
evidence from the initial view or PNG.
Perform this review yourself before presenting a complex visual; the person
should not need to request a screenshot check separately.
When a view is crowded, show the meaningful subset or aggregate first. Retain
the complete source data and explain the initial slice. Make additional series,
layers or views available through catalog-supported selectors, filters, tabs
or optional-view controls, with readable labels and visible inclusion state.
Do not invent a visibility property or hide contrary evidence to improve the
story. Check the revealed detail as well as the quiet default.

Use annotations to point to evidence during explanations and questions.
Update a chart with supported layered marks for a labelled point, red outline,
range or trend; keep the original rows and quantitative encodings intact.
Use real data coordinates or stable entity IDs when a mark should follow
zoom/filter changes. A pixel-positioned mark belongs to one captured viewport;
do not reuse it on a different view as if it still identifies the same data.
Annotations clarify evidence; they do not change measurements or submit an
answer. `ask_user` continues to own question submission independently.

For worked decision patterns, load `references/investigation-patterns.md`
from this skill. Stop once the question is resolved and the relevant views
are readable; further captures should answer a remaining concern. Keep visual
observations, calculations and unresolved uncertainty distinct in the answer.

Keep the final response focused on the requested deliverables and findings.
`capture_a2ui_surface` retains its screenshots as verification evidence; do not
register or list each capture as another output. For other review images/PDFs,
use `create_artifact(..., purpose="verification")`; working files use
`purpose="intermediate"`. Both remain accessible in Observability and lineage.
Requested images/PDFs use `purpose="deliverable"`. When revising an output,
keep its artifact family/name; the response presents its latest deliverable
version while Versions and Observability retain earlier attempts.