/build-a-dashboard

name: build-a-dashboard
description: Turn a question the user keeps asking about production (error rates, latency, signups, cost) into a saved Sazabi dashboard built from live log queries — check the fields exist, validate before saving, and confirm every panel returns data. Use when the user asks for a dashboard, a recurring view or report, or says they keep checking the same numbers.
argument-hint: what the dashboard should show, and for which service or project
allowed-tools: mcp__sazabi__search, mcp__sazabi__execute

A dashboard is a saved question

A Sazabi dashboard is a page of live panels, each running a log query when the dashboard opens. Build one for questions that come back every day or every deploy; answer one-off questions with `sazabi/logs.ask` instead.

0. How the tools work

The Sazabi MCP server lists only two tools, `search` and `execute`. Browse Sazabi's operations with `search` and `namespace: "sazabi"` (an empty query without a namespace lists connected connectors, not Sazabi operations). Before calling one, repeat `search` with `namespace: "sazabi"`, the hit's full name as the query, and `includeInputSchema: true` to load its arguments. Then run it with `execute` as `{ name, arguments }`, the name copied from the hit (for example `sazabi/logs.ask`). Dashboard operations: `sazabi/dashboards.list`, `.get`, `.validate`, `.create`, `.update`, `.render`, `.delete`.

1. Check what exists

Run `sazabi/dashboards.list`. Every project has built-in dashboards (issues and alerts, log health) that can't be edited but can be copied. If a close match exists, propose editing or copying it rather than adding another.

2. Find the real fields

Pin down each panel as a question with a number: "error lines by service per 15 minutes", "p95 request duration by route". Use `sazabi/logs.ask` to confirm the logs actually carry the fields each panel needs (service, route, duration, event name). If a signal isn't in the logs, leave that panel out and say what would provide it, for example the `add-logging` skill. Never invent a field.

3. Write, validate, save

A dashboard is one MDX document: a `DashboardMeta` block (title, description, default time range) and a grid of panels, each with an inline log query. A panel's query never names a time range; the dashboard supplies it. Copy the document shape from `dashboards.validate` and from an existing dashboard via `dashboards.get`.

Run `sazabi/dashboards.validate` and fix every diagnostic (each names its line and a repair hint), then `sazabi/dashboards.create`. Generate the dashboard id yourself and reuse it if you retry. To change a dashboard, `dashboards.get` it, edit the whole document, and `dashboards.update` with the edit base it returned. If the update is rejected because someone saved a newer revision, re-read and re-apply; don't overwrite.

4. Prove it renders

Run `sazabi/dashboards.render` over the default window and check every panel returns ok, not empty or rejected. Fix or drop panels that don't. Reply with the dashboard link and one line per panel.

Anti-patterns

• **Twenty panels.** Five panels that answer the question beat twenty that

don't.

• **Deleting shared dashboards.** A delete removes it for the whole project and

can't be undone; ask first.

• **Shipping an empty panel.** A panel that renders "No data" on day one

teaches people to ignore the dashboard.