designing-dashboards

这段内容是审核时保存的快照。外部来源才是完整且最新的版本。

---
name: designing-dashboards
description: "Design modern, actionable dashboards through a collaborative, taste-aware workflow. Use for any dashboard task—building new dashboards, revamping existing ones, choosing layouts, selecting charts, designing widgets, deriving a theme, or validating a design. Acts as a navigator: pitches options, adapts to the user's taste and codebase, keeps rich widgets that earn their place, and verifies the result by measurement—never assumes preferences."
---

# Dashboard Design Skill

A **navigator, not a prescriber.** This skill guides you toward a well-made dashboard
by pitching suggestions and adapting to the user's taste, their codebase, and their
audience. It keeps the rich, interpretive widgets that separate a real dashboard from a
generic one — and it earns every element rather than padding or stripping by reflex.

**Two operating beliefs:**
- **Rich by intent, not by reflex.** Charts, insights, and composed widgets are the
  value. Keep them whenever they do real work; cut only the *gratuitous*.
- **Verify, don't attest.** A dashboard isn't done because a checklist is ticked — it's
  done when the rendered output has been measured.

## How this skill works

Progressive disclosure: the workflow and principles live here; depth lives in reference
files, loaded when a phase needs them.

| Phase | Reference | Use when |
|-------|-----------|----------|
| Requirements | [requirements.md](requirements.md) | Starting out; scanning the project; gathering only what's ambiguous |
| Strategy | [strategy.md](strategy.md) | Classifying the dashboard, audience archetype → visualization density budget |
| Layout | [information-architecture.md](information-architecture.md) | Layout patterns, launchpad/drill-down, dashboard-level interaction (filters, date range, URL state) |
| Visualization | [visualization.md](visualization.md) | Right-medium check, chart selection, selection≠execution, chart→library mapping |
| Design system | [design-system.md](design-system.md) | Tokens (single source), theme sourcing (light/dark · derive · vibe), numeric craft, dark mode |
| Widgets | [components.md](components.md) | Widget anatomy as a menu; implementation conventions (Recharts + Tremor / project lib) |
| States | [edge-states.md](edge-states.md) | Empty / loading / error — always required |
| Validation | [validation.md](validation.md) | The measured loop: render → screenshot → contrast → breakpoints → scored rubric |

---

## First: New or Revamp?

**Revamp (improving an existing dashboard) → audit first, then diff.** Don't design from
blank. Audit the current dashboard widget-by-widget: *what does each one show, what
decision does it support, what's weak or missing?* Diff that against the target, then
improve. The existing layout is the **baseline to beat, not a template to copy.**

**New (greenfield) → go to Requirements.** Start from the audience and the questions the
dashboard must answer.

Either way, run the **project-context scan** early (see Principle 7).

---

## The three gates

Lightweight collaboration — ask only what genuinely changes the design, then move.

| Gate | When | What |
|------|------|------|
| **Clarify** | Before strategy | Resolve only *genuine* ambiguity (audience, theme source, must-show metrics). Don't interrogate. |
| **Propose** | Before building | Pitch strategy + layout + theme sourcing as options; confirm direction. |
| **Validate** | After building | Run the **measured loop** (validation.md), then the advisory subtraction pass and scored rubric. |

Scale the ceremony to the task: a quick concept needs one Clarify question; a
production revamp warrants all three gates in full.

---

## Core principles

**1. Charts + insights.** Every visualization that stays carries a headline insight that
adds what the chart doesn't already show — a cause, comparison, anomaly, implication, or
next action. *Bar: would a sharp analyst bother saying this out loud?* If the best you
can write restat