Use dashboard-spec

Spec a dashboard before anyone builds it

Spec a dashboard before anyone builds it — the audience and the decision it serves, the questions in priority order, one chart per question with the chart type and why, the defined metric behind each chart, filters, refresh cadence and freshness SLA, and a list of what is deliberately left off, with vanity metrics cut.

Reach for it when the user says "spec a dashboard", "what should go on our KPI dashboard", "the BI team needs requirements for a dashboard", "our dashboard has 40 charts and nobody uses it", or "design the exec dashboard".

Install it

npx skilldrop-cli install dashboard-spec                 # Claude Code, your user folder
npx skilldrop-cli install dashboard-spec --project       # Claude Code, this repo
npx skilldrop-cli install dashboard-spec --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the Data and analytics pack: --pack data-analytics installs it with its neighbours.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "Spec a dashboard for our weekly ops review before the BI team builds it"
• "What should go on the exec KPI dashboard? Here's the list everyone asked for"
• "Our marketing dashboard has 40 charts and nobody uses it, redesign what goes on it"
• "Write the requirements for a Looker dashboard for the finance team"

Requests like these belong to a different skill, so it shouldn't answer them:

• "Define exactly how monthly recurring revenue is calculated"
• "Design SLOs, alerts and the service health dashboard for the payments API"
• "Pick the success metrics and targets for the new search feature"

If another skill answers instead, ask for this one by name: "use dashboard-spec".

Check what you get

A good result:

• A one-sentence decision statement names who decides what, and how often.
• At most seven questions, in priority order, each with the action a bad answer triggers.
• One chart per question, with a type and a reason. No chart without a question.
• Every chart names a metric by its defined name, or flags it undefined as a build blocker.
• Every number tile carries a comparison.
• Filters are four or fewer, have defaults, and never fan out a metric.
• Refresh cadence matches the decision cadence, with a freshness SLA and a visible stale-data behaviour.
• A cut list exists, with a reason for each item, and vanity metrics are on it.
• Nothing is invented. Metrics, targets and data sources not given are marked [assumption] or undefined.

See a worked example

• support staffing

Use something else when

• Defining how one metric is calculated (formula, filters, timezone) — that's the metric owner's call; this skill flags the gap, it doesn't fill it
• Choosing which metric judges a feature, with targets and a decision rule — that's success-metrics
• Service health dashboards, SLOs and alerting — that's observability-plan
• A report on AI tool usage from telemetry logs — that's ai-usage-report

Where a loop runs it

• Stage spec of the measure loop

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: ai-usage-report, observability-plan, success-metrics

Edit this page on GitHub · View source