datadog-design-dashboard

これはレビュー時に保存された抜粋です。完全で最新の内容は外部ソースを確認してください。

---
name: datadog-design-dashboard
description: "Design new Datadog dashboards, redesign existing ones, or audit dashboards for operational readiness. Covers widget selection, layout organization, template variables, group structure, tab organization, alert threshold validation, and zero-knowledge readability. Uses pup CLI for inspecting dashboards and validating designs. Use when designing new dashboards, redesigning existing ones, auditing before on-call handoff, or reviewing after dashboard changes. Do not use for: (1) Datadog agent installation or configuration, (2) monitor/alert rule design, (3) APM instrumentation or tracing setup, (4) log pipeline configuration."
allowed-tools:
  - AskUserQuestion
  - Write
  - Read
  - Shell
---

# Design Datadog Dashboard

Design a dashboard layout that tells a clear story — from high-level health signals down to granular diagnostics — using proper widget types, group organization, and template variables for reusability.

**Important**: Always check for existing dashboards first with `pup dashboards list --agent`. Do not create a new dashboard if one already exists for the same service or purpose — update the existing one instead. Only create a new dashboard when no relevant one exists or the user explicitly asks for a new one.

**Philosophy**: The frameworks, layouts, and widget guides in this skill are starting points — not rigid rules. Every product and business is different. Understand the domain first, then adapt the frameworks to fit. The best dashboards reflect how the business actually works, not how a generic template says they should.

---

## Interview

First, determine the mode:
- **Design mode** — user wants to create or redesign a dashboard → ask design questions, then run the full workflow
- **Audit mode** — user wants to review an existing dashboard with no intent to redesign → skip to [Audit](#audit)

### Design Questions

**Skip if ALL of these are already specified**: dashboard purpose, target audience, data sources, template variable needs, dashboard strategy.

1. **Purpose** — "What is this dashboard for? Service overview, infrastructure, executive KPIs, debugging, or SLO tracking?"
2. **Audience** — "Who will use this? On-call engineers, platform team, leadership, or mixed?"
3. **Data Sources** — "Which Datadog products are involved? Metrics only, APM + Metrics, Logs + Metrics, or full stack?"
4. **Scope** — "Is this for a single service, a group of services, or infrastructure-wide?"
5. **Dashboard Strategy** — "One dashboard per service, or a consolidated view?" — share the trade-offs from [references/layouts.md](references/layouts.md) to help them decide. If unsure, ask: "During an outage, does your team investigate one service at a time, or do they need to see all services simultaneously?"
6. **Existing Dashboard** — "Is there an existing dashboard to audit or redesign?" If yes, fetch with `pup dashboards get <id> --agent` before designing.

### Audit Questions

**Skip if ALL of these are already specified**: dashboard ID or URL, service name or team context.

**Always interview if**: No dashboard ID is provided or multiple dashboards may be relevant.

1. **Dashboard** — "Which dashboard should I review? Provide a dashboard ID, URL, or service name to search for."
2. **Business Context** — "Can you tell me what this service does for customers? Are there codebases or docs I can read to understand the product?"
   - Impact: Understanding the domain lets the review focus on whether the right metrics are being tracked, not just whether generic rules are followed
3. **Focus** — "Is there anything specific you want me to focus on? (A) Full review, (B) Alert thresholds only, (C) Business section, (D) Layout and readability"
   - Default to full review if unspecified

---

## Domain Discovery

*Applies to design mode. Skip if auditing only.*

Before designing, understand what you are building observability for. The metrics that matter depend entirely on the product an