Update to Altertable

{
  "description": "Creates and updates persistent Altertable Dashboards composed of Insights, text, sections, variables, and grid positions. Use only when the user requests an Altertable-hosted dashboard or changes to an existing Altertable Dashboard; do not use for generic or client-native dashboards, reports, or visualizations.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 120
    }
  ],
  "name": "build-dashboards",
  "skill_md_contents": "---\nname: build-dashboards\ncompatibility: Requires Altertable MCP server; saving or updating requires read-write access\ndescription: \"Creates and updates persistent Altertable Dashboards composed of Insights, text, sections, variables, and grid positions. Use only when the user requests an Altertable-hosted dashboard or changes to an existing Altertable Dashboard; do not use for generic or client-native dashboards, reports, or visualizations.\"\nmetadata:\n  author: Altertable\n  requires: \"altertable-mcp\"\n---\n\n# Build Dashboards\n\nDashboards are persistent Altertable objects that arrange saved or inline Insights with explanatory text, sections, grid positions, and shared variables. Build them when several analyses need a reusable coordinated view in Altertable.\n\n## Routing Boundary\n\nUse this skill only when the intended destination is Altertable: the user explicitly asks for an Altertable dashboard, identifies an existing Altertable dashboard, or requests Altertable-specific dashboard capabilities such as Insight widgets or shared variables. A generic request for a dashboard, report, visualization, or interactive artifact does not imply Altertable persistence. Prefer the client's native dashboard or artifact capability unless the user explicitly wants the result created or maintained in Altertable.\n\nDo not call `create_dashboard` as a rendering convenience or merely because Altertable supplied the data. Creating an Altertable Dashboard is a persistent write and requires explicit user intent.\n\nKeep dashboard copy concise. Use text widgets only for context needed to interpret or act on the data.\n\n## Workflow\n\n1. Confirm the intended environment and write scope.\n2. Use `list_insights` and `read_resource` at `altertable://ontology/entities/{slug}` to inspect saved analyses. Verify a saved Insight by passing its slug as `insight` to `render_insight` on a user-facing surface, or to `execute_insight` when no viewer should be attached. Build or repair missing Insights before laying them out.\n3. Use `list_dashboards` to discover saved dashboards. Without a query it returns metadata ordered by popularity; pass `query` to filter by title or description. Before changing one, read its full definition with `read_resource` at `altertable://ontology/entities/{slug}`. Preserve widgets and variables the user did not ask to replace.\n4. Define the audience, operating question, refresh cadence, and shared filters.\n5. Arrange the most decision-relevant metrics first, followed by drivers and diagnostic detail.\n6. Call `create_dashboard` for an explicitly requested new dashboard, or `update_dashboard` for an existing slug.\n7. Read the saved dashboard back with `read_resource` and check widget references, variables, and grid positions.\n\n## Altertable Objects\n\n- Insight widgets can reference saved Insight slugs or contain inline Insight definitions.\n- Text widgets explain definitions, caveats, or decisions without creating another query.\n- Section widgets group related charts.\n- Variables apply shared values across widgets through explicit mappings.\n- Labels support organization and retrieval.\n\nUse the live tool schema for widget kinds, grid coordinates, variable definitions, and mappings. Do not invent a dashboard JSON shape from an old example.\n\n## Update Semantics\n\nWidget and variable lists replace current values when supplied to `update_dashboard`. Read the existing dashboard with `read_resource` first, merge intended changes locally, and send the complete retained lists. Omitting a field leaves it unchanged.\n\nDo not silently create duplicate Insights to populate a dashboard. Reuse an existing Insight when its definition and variables match; use an inline definition for dashboard-specific analysis when supported and appropriate.\n\n## Verification\n\n- Every referenced Insight resolves and executes.\n- Variable defaults and mappings work across all intended widgets.\n- Grid positions do not overlap unintentionally.\n- Titles, units, time grains, and filters are consistent.\n- Empty and partial-data states remain understandable.\n- The dashboard contains no sensitive raw values that aggregates could replace.\n\nAttach a scheduled Task only when the user requests recurring monitoring; use `configure-tasks` for that operation.\n"
}