| name | data |
| description | Data analysis skill hub. Routes to the right specialist subskill depending on the request — exploration, query writing, end-to-end analysis, visualization, validation, dashboard planning plus assembly, or recurring snapshot refresh.
|
| plugin | data-analytics |
| inherits_plugin_defaults | true |
data — Skill Hub
This hub describes when to use each subskill in the data/ family. Load the most
specific subskill that matches the request; fall back to data/analyze for general
analysis tasks.
Subskill routing
| Request type | Load skill |
|---|
| "What tables / columns / data do I have?" | data/explore |
| "Write me a SQL query to…" | data/query |
| "Analyze / what's happening with…" (general) | data/analyze |
| "Chart / visualize this…" | data/visualize |
| "Check / validate this analysis before I share it" | data/validate |
| "Build me a dashboard" | data/dashboard |
| "Refresh this every day / keep this report in sync" | data/refresh |
Spreadsheet routing:
- Load
xlsx when the user wants an Excel/CSV/TSV workbook file created, edited,
cleaned, formatted, recalculated, charted, or converted.
- Load a
data/* skill when the spreadsheet or tabular file is the input to an
analysis, SQL query, chart, dashboard, validation, or recurring data snapshot.
- Do not treat
.xlsx, .xls, .ods, or .parquet files as UTF-8 text. Use
the document inspection tools or data plugin scripts.
Connector selection (apply in every subskill)
Choose the right data connector for the source:
- Warehouse (managed datasets, large tables) — use the BigQuery MCP server
(
toolbox-bq-demo) for discovery and scoped SQL. Treat BigQuery as the source of
truth. When repeated local slicing is needed, create or use a workspace snapshot
first, then continue through plugin scripts.
- Local files (CSV / Parquet / JSON in the workspace) — use
run_skill_python_script with data_workspace for schema inspection, DuckDB
queries, profiling, and exports.
- Charts / tables / reports — prepare payloads with plugin scripts, then validate
and render bounded payloads through the
data-artifacts MCP.
- Recurring dashboards / canned reports — use
data/refresh to publish stable
snapshots such as datasets/<slug>/latest.parquet, then regenerate stable native
dashboard or report artifacts from those snapshots.
- Dashboard creation —
data/dashboard is review-first. It should inspect the tagged
dataset/report context, propose a dashboard plan, wait for approval, then generate the
native DashboardCanvas package with build_native_dashboard_package.
- Do not attempt cross-source SQL joins in v1. Orchestrate at the workflow level
(query each source separately; combine in Python / summary prose).
Guardrails that apply to every subskill
- Inspect schema / metadata before executing SQL.
- Always cite concrete numbers (counts, averages, %, deltas). No speculation.
- Keep query and script runs bounded; prefer 5 focused queries for a normal analysis
and stop by 10 unless the user explicitly asks for deeper investigation.
- Maximum 5 charts per run.
- One shareable deliverable path per run: report artifact or native dashboard package.
- Reports and dashboards only include artifacts from the current run — never
from prior runs.
- Dashboard requests should prefer a tagged dataset artifact as the source of truth and
avoid fresh warehouse rediscovery unless the tagged inputs are unusable.
- In
data/dashboard, pass structured chart bindings to
build_native_dashboard_package; do not generate dashboard.snapshot.html.
