vista-dashboard

name	vista-dashboard
description	Push live status updates to the Vista dashboard so the user can see what you're doing visually instead of reading prose. Use whenever Vista's dashboard_* MCP tools are available — typically auto-installed by `vista init`.

Vista Dashboard skill

You have access to a set of dashboard_* MCP tools (provided by the Vista dashboard daemon). When they are available, call them while you work so the user has a glanceable, project-aware view of your progress.

Heuristic for when to call which tool:

Always

• At the start of any non-trivial task, call dashboard_set_status with status: "working" and a short action label (≤ 8 words).
• When you switch sub-tasks, call dashboard_set_status again with a new action label. Don't spam — only when the action genuinely changes.
• When you finish, call dashboard_set_status with status: "done".
• If you're blocked (e.g. you need a credential, need the user to choose), call dashboard_set_status with status: "blocked" and explain in the action label.

Web apps (Next.js, Vite, FastAPI, Flask, Django)

• When you touch an HTTP route — handler, page, layout, API endpoint — call dashboard_set_route with the path, method, and (if known) the latest status code. Set is_new: true if the route didn't exist before.
• When the dev server is running and the route renders, call dashboard_add_screenshot with a label (the route path) and a url pointing to the local URL (e.g. http://localhost:3000/dashboard). If you cannot fetch the page yourself, just include the label and status and Vista's screenshot worker will fill in data_url later.

Data pipelines (Dagster, Airflow, dbt)

• For each pipeline node you create, modify, or run, call dashboard_set_dag_node with id, label, kind, status, and (if known) row_count and upstream (array of node IDs).
• When a node runs, transition its status: pending → in_progress → completed (or failed).

Anything with tests

• When you run a test or learn its result, call dashboard_set_test with file, name, status ∈ {pass, fail, skip, pending}, and optionally duration_ms.

Notable log lines

• For dev-server output, build errors, or important runtime messages, call dashboard_log with source (e.g. next-dev, pytest), level (info/warn/error), and the message.

Do not

• Do not call any dashboard_* tool more than once per second for the same field — batch related updates.
• Do not narrate every internal thought; the dashboard is a status surface, not a transcript.
• Do not block on dashboard tool failures — they are best-effort.

Session identity

If you don't know your session_id, use the literal string "default". The daemon will route updates to the currently-focused session.