shared/shared-skill-instructions.md

# Shared Data instructions

Keep the user’s task, source restrictions, selected context, requested output and prior answers across handoffs. The [index](../skills/index/SKILL.md#shared-instructions-table-of-contents) maps shared guidance; directly invoked skills supply their own applicable links and need no index round trip. Read the selected workflow and currently applicable references in one parallel batch **before the action they govern**, with enough output capacity for each read and the enclosing batch. Defer later branches. A capability answer, welcome or named tour uses its own short path.

Reuse instructions already loaded for this task, including by another skill. Treat repeated links and “read before use” requirements as satisfied by complete text in context. Fetch only missing or truncated sections, or changed instructions; do not restart a reading bundle at a skill handoff. The index owns the file-read tool settings.

## Task preferences

Apply explicit task choices, selected templates, and relevant context skills before defaults. Choose balanced chart spacing unless specified. Existing Data Context and Working Preferences layouts remain usable: preserve names, owner, audience and metric meaning; style preferences neither redefine a governed measure nor authorize external actions. Keep newly learned semantics scoped to this task unless persistence is requested.

This release has no saved Data settings or settings tools. Do not read, write, migrate or delete old preference files. If asked to change a setting, explain that limit and apply the preference now. Use [Customize Data Plugin](../skills/customize-data-plugin/SKILL.md) for explicitly requested reusable guidance. Presentation-only or packaging work needs no unrelated source discovery.

## Analysis records and companion artifacts

Keep exact queries, inputs, calculations and source references inspectable in working scripts or the selected output's source metadata. SQL, Python or a multi-step analysis does not by itself call for a notebook. Create, render or export additional notebooks, workbooks, decks or other companion deliverables only when the user requests them; use the notebook workflow for requested notebook work. Deliver the presentation selected by the index, including its charts, source details and any scope-triggered report, without packaging extra formats. An available export menu is not a request to generate exports.

## Links in the conversation

Match the final response to the task. For artifact creation, identify and link or preview the deliverable; add a takeaway when useful. For an analytical question, answer with the key evidence and implication, then link any companion report or dashboard. Delivered Page reports use the [Page handoff](output-and-template-handling.md#opening-and-report-handoff). A standalone answer needs enough explanation to be useful on its own. Omit contents inventories and unrequested implementation details; mention the format only when it helps the user choose or open the deliverable.

Preserve limits of the evidence that could change the user's interpretation or decision. Keep validation evidence and routine operational details, such as an unperformed mobile check, in the working record. Mention an operational issue when it affects access, use of the deliverable, or an explicitly requested capability; explain the practical consequence. Ask for missing input only when it changes what can be concluded or done.

- Useful: “Active-user rates rose from 40% to 45%, up 5 percentage points: a larger share of eligible users completed a task this week.” Follow with the linked weekly KPI report.
- Avoid: “Includes a chart, interpretation, and assumptions; verified at desktop and mobile sizes.”

Adapt the wording to the task.

Use descriptive clickable Markdown in progress, sources and handoff: `[title](verified URL)`. For a desktop file use its absolute path, with angle brackets around a destination containing spaces or parentheses; for a cloud file or Page use the actual supported download or user-facing URL. Do not invent a destination, expose a remote path as a local file, or present a bare URL as the user’s link.

For HTML delivery use the [verified live URL and selected view](data-app.md#publication-and-final-delivery); a filesystem HTML link may open source, not a rendered preview. Respect file-only requests and label any permitted fallback. Native inline visualizations retain their own delivery syntax.

## Accessible colors and appearance

Keep marks, text, legends and tooltips legible against the actual host in light and dark mode, including charts on a Page or its source subpages. Respect requested colors and stable series meanings; supplement color with labels, shapes or line styles. Start from a complete supported theme, map each series to a valid color, and inspect expected marks in both supported modes after appearance changes. A successful build or empty chart frame is not visual verification; record which checks ran and which were unavailable.

## Chart surfaces and style

For inline answers, use the installed Visualize skill and its current host delivery contract with reviewed values. Dashboards and HTML/Sites reports use the existing Data app runtime and its documented chart components; use [visualize-data](../skills/visualize-data/SKILL.md) when chart selection or implementation needs guidance. Explicitly selected Pages use the [Page guide](../skills/build-report/references/spaces-report.md) and supported native visualization tools. Preserve units, series colors, readable typography and the selected theme across surfaces. When exact comparison matters, use readable value labels or an adjacent table; hover or collapsed details should not be the only route to those values. For an explicitly requested static figure or image-only format, use an appropriate reproducible renderer and inspect the exported result.

### Preserve charts during verification

**Verification must not destroy working output.** Preserve the existing chart components, configuration, embed references, interactions, and layout while checking them. Preservation means retaining the delivered chart, not merely saving its configuration or a backup. A chart the user confirms works must remain intact unless they request a change or a specific defect is established.

- Inspect the actual delivery surface. Bring the chart into view and allow up to **7 seconds** from when it starts loading to render. If it has not rendered after 7 seconds, treat that as a real rendering error and investigate; do not continue calling it normal loading. Record the surface and observed timing. Do not repeatedly reload or restart the clock.
- An isolated blank screenshot, incomplete accessibility snapshot, cross-origin iframe inspection limit, selector/tool timeout, or unrelated console warning does not identify a chart defect. Distinguish these inspection limits from an observed failure to render within 7 seconds. A preview in another browser cannot overrule a working destination or the user's observation.
- A generic host notice such as "An error occurred inside the visualization" does not establish a defect in the chart implementation. Recheck the same artifact without reloading; distinguish a host/inspection problem from the chart's own error. A successful standalone rendering is reason to preserve that implementation while investigating delivery.
- Before changing an implementation, record a specific reproducible configuration, data, reference, or component defect and repair it in place. Check each affected embed separately: a problem on the report does not establish a problem on its source Pages or other charts. Do not regenerate charts, rebuild the report, or switch formats to make a preview check pass.
- If inspection remains inconclusive, retain the existing interactive embeds and record rendering as unverified. If the 7-second deadline is exceeded or a rendering error is observed, record a rendering failure with its cause unresolved until diagnosed. Check CDN loading, host/iframe startup, and the chart's own errors; preserve the component while applying a scoped repair, and report unresolved delivery limitations. An optional static fallback must be separate from the original chart; never delete or replace an interactive embed with an image as a verification recovery. Backing up its HTML or references does not authorize removing it from the report or source Page.

Use static SVG/images only for an actual rendering or delivery fallback, a specific chart whose required encoding cannot be rendered faithfully otherwise, an image-only destination such as a Markdown report, or an explicitly requested static/export figure. SVG marks inside a working interactive chart are not a static-file fallback. Preserve reviewed values, inspect the image and deliver it in the selected surface; a small dataset alone does not justify replacing the interactive chart with a static asset.