signoz-creating-dashboards

What this skill does

# Dashboard Create

Build a SigNoz dashboard from a user's natural-language intent. The skill
targets two consumers: an autonomous AI SRE agent that runs without a
human in the loop, and a human at a Claude Code / Codex / Cursor prompt.
Both go through the same flow.

## Prerequisites

This skill calls SigNoz MCP server tools (`signoz:signoz_create_dashboard`,
`signoz:signoz_list_dashboards`, `signoz:signoz_list_dashboard_templates`,
`signoz:signoz_import_dashboard`, `signoz:signoz_get_dashboard`,
`signoz:signoz_update_dashboard`, `signoz:signoz_list_metrics`,
`signoz:signoz_get_field_keys`, `signoz:signoz_get_field_values`,
`signoz:signoz_aggregate_logs`, `signoz:signoz_aggregate_traces`, etc.).
Before running the workflow, confirm the `signoz:signoz_*` tools are
available. If they are not, the SigNoz MCP server is not installed or
configured — run `signoz-mcp-setup` first to initialize or repair the MCP
connection. Do not fall back to raw HTTP calls or fabricate dashboard JSON
without the MCP tools.

## When to use

Use this skill when the user wants to:
- Create, set up, or build a new dashboard.
- "Monitor" or "set up observability" for a service, database,
  infrastructure component, or AI/LLM platform.
- Import a curated dashboard template.
- Visualize a set of metrics / traces / logs together on one screen.

Do NOT use when the user wants to:
- Modify an existing dashboard → `signoz-modifying-dashboards`.
- Understand what an existing dashboard shows → `signoz-explaining-dashboards`.
- Run a one-off query without persisting it → `signoz-generating-queries`.

## Required inputs (strict)

Dashboard creation is a write operation. Guessing here clutters the
shared workspace with empty or wrongly-scoped dashboards someone else has
to clean up. The skill enforces a soft input contract — most fields have
sensible defaults, but a few cannot be guessed:

| Input | Required | Source if missing |
|---|---|---|
| Dashboard intent (NL goal) | yes | `$ARGUMENTS` or recent user turn |
| Technology / domain (e.g. PostgreSQL, Redis, "payment pipeline") | yes | parse from intent; otherwise ask |
| Modify-or-create choice when duplicates exist | yes | ask the user (Step 2) |
| Resource scope for custom builds (service / namespace / cluster) | yes for custom builds | discover via `signoz:signoz_get_field_keys` + `signoz:signoz_get_field_values`; fall back to a dashboard variable |
| Specific metrics / signals for custom builds | inferred | derive from technology + MCP `signoz://dashboard/*` resources; surface in preview |
| Default time range, refresh, layout | inferred | apply defaults (see "Defaults" below) |

If a required input is missing and cannot be discovered, **stop before
calling any write tool** and ask the user. The host application decides
how the question is surfaced (a structured clarification tool, inline
`<assistant_question>` tags, an interactive prompt, etc.) — follow the
host's UI rendering rules.

What to include in the question:

- **What is missing** — name the input concretely (e.g. "no service or
  cluster specified for the custom build").
- **Candidate lists** populated from your discovery calls — concrete
  values per attribute the user can pick from. Example shape:
  `service.name` → `frontend`, `checkout`, `payments`, `inventory`;
  `k8s.cluster.name` → `prod-us-east-1`, `staging`.
- **Allow free-form input** so the user can name a value you didn't
  surface.

In autonomous mode (no human), escalate to the caller or fill the gap
from upstream context. Either way, do not proceed to
`signoz:signoz_create_dashboard` / `signoz:signoz_import_dashboard` with
a guessed value.

## Workflow

The flow runs in order: **duplicate check → user picks modify-or-create
→ on create, template lookup decides template-import vs custom-build →
no-data probe → per-panel dry-run → preview → save**. Duplicate check
comes first so we never silently create a second copy of something that
already exists. Once the user has chosen to create, the template lookup
is an internal implementation detail — if a curated template fits we
use it, otherwise we build from scratch. The per-panel dry-run
(`signoz:signoz_execute_builder_query` against every query-bearing
panel) is mandatory before save — a saved empty panel from a typo'd
attribute or wrong severity filter is the worst failure mode for this
skill, and dry-run is the only step that catches it. The user is
offered exactly two upfront choices: modify an existing dashboard, or
create a new one.

### Step 1: Check for duplicates

Call `signoz:signoz_list_dashboards`. Most installs fit in the default
page (`limit=50`); only paginate when `pagination.hasMore=true`. Use
string values for `limit` / `offset` (e.g. `"50"`, `"0"`) — the schema
expects strings, not integers.

**Match by relevance** Compare each existing
dashboard's lowercased `name`, `description`, and `tags` against the
user's technology/domain. Surface only matches a human would recognize
as the same thing — a "redis" dashboard does not match a "postgresql"
request just because both have a `database` tag. Collect each match's
`name`, `uuid`, and `createdAt` for the next step.

### Step 2: Ask the user — modify or create

Present exactly two options (no template-import as a separate top-level
choice — that's an internal decision in Step 3b):

- **Duplicates found:** "There are already these similar dashboards:
  [list with name, UUID, created-at]. Want me to (a) modify one of
  these, (b) create a new dashboard anyway, or (c) stop?"
- **No duplicates:** "I'll create a new dashboard for this. Proceed?"
  (No "modify" option when there's nothing to modify.)

Wait for the user's choice. "modify" → Step 3a. "create new" / confirm
→ Step 3b. "stop" → stop.

### Step 3: Create or modify

#### Step 3a: Modify an existing dashboard

Hand off immediately to `signoz-modifying-dashboards` with the chosen
dashboard UUID and the user's intent. Do not call
`signoz:signoz_update_dashboard` from this skill — modification is out
of scope. (See "Scope boundary" in Guardrails.)

#### Step 3b: Create a new dashboard

Run the template lookup first. The user has already agreed to create
new — the lookup decides *how* we build it.

Call `signoz:signoz_list_dashboard_templates` once with no arguments.
The full catalog (~95 entries) returns in a single call — read it
in-context and pick the best match for the user's intent. When several
entries plausibly fit, present the top 3–5 and let the user choose.

Branch on the result:
- **Single clear template match** — proceed to Step 3b-i (template
  import). Briefly tell the user "I found a pre-built [title] template
  and will use it" so they know what's being created; do not block on
  yes/no.
- **Multiple plausible matches** — present them and ask the user to
  pick. Once picked, proceed to Step 3b-i.
- **No template** — proceed to Step 3b-ii (custom build).

#### Step 3b-i: Import the template

> **Tool guardrail** The only template tools are
> `signoz:signoz_list_dashboard_templates` and
> `signoz:signoz_import_dashboard`. Do not shell out, fetch raw GitHub
> URLs, or invent other tool names.
> `signoz:signoz_import_dashboard` takes the template `path` from the
> catalog entry and creates the dashboard in one call — you do not need
> to fetch the JSON yourself or call `signoz:signoz_create_dashboard`
> afterwards.

##### Step 3b-i.1: Pre-flight no-data probe (fail fast)

Before calling `signoz:signoz_import_dashboard`, confirm the template's
signals are actually being ingested. The most common silent failure for
template imports is "the template imports cleanly but every panel reads
'No data' because the technology isn't being scraped" — the user only
discovers it after clicking through to a useless dashboard.

Since we don't fetch the template body up front, base the probe on the
catalog entry's `category`, `title`, and `keywords` plus the user's
stated technology. Pick up to ~5 representative signals and check them
— keep the t