Visualize

Use show_widget when seeing or interacting with a result helps the user reason about it. This includes code architecture, execution traces, performance, comparisons, simulations, UI mockups, and session dashboards. Use prose, a normal Markdown table, or a supported Mermaid block when that already explains the answer. A request to implement an application still needs changes in its project; a widget can illustrate the design but does not complete the implementation.

Choose the surface

• Code work and one-off explanations: prefer inline when available this turn. Show the actual owners, relationships, measured values, or states relevant to the question. Distinguish proposed designs and illustrative data from observed behavior. Several diagrams for a code task do not by themselves call for a dashboard.
• Persistent dashboards: use pin: true for an explicit dashboard request or multiple non-code visualizations that belong together. Read the current board first and reuse its names and tabs. Use the control-ui skill when organizing sessions, tabs, placement, or dashboard presentation.
• Native reports: prefer the tool's report input with pin: true for dashboard text, metrics, tables, simple charts, and links. Omit widget_code, kind, capabilities, and presentation.target. Reports do not render inline.
• Custom widgets: use widget_code for interactive HTML/SVG. Reuse an explicit name with pin: true to replace a pinned widget's content. A same-name update cannot change its content owner; inspect before converting HTML to a report.

Use only tools, source kinds, and presentation targets advertised in this turn. On a pinned-only surface, set pin: true and omit presentation.target. If the tool is unavailable, explain the limitation instead of inventing a render call. Restart recovery can be pinned-only even when the original turn supported inline widgets; follow the current tool schema instead of earlier delivery instructions.

Author the content

Send the markup itself in widget_code. Use an HTML or SVG fragment, optionally including <style> and <script>; OpenClaw supplies the document shell, theme, and host bridges. Do not send a file path, Markdown fence, full HTML document, or another application's visualization directive. title is host metadata: start with useful content rather than repeating the title or drawing dashboard chrome.

Keep a useful initial state in the markup. Use local JavaScript for selections, filters, parameter changes, and animation. Give the root a unique ID and scope styles and selectors to it. Insert labels and external data with textContent instead of interpolating untrusted strings into markup or executable code.