Check whether a dashboard can be trusted before a decision. — Claude Skill
En Claude-skill för Claude Code av ElasticFlow✓ — kör /dashboard-audit i Claude·Uppdaterad 12 juni 2026·vmanual@2026-06-12
Reviews dashboard definitions, freshness, filters, owners, source systems, and obvious contradictions so teams know whether the numbers are safe to use.
- Explains whether dashboard numbers are decision-ready, stale, inconsistent, or missing context.
- Checks metric definitions, filters, date ranges, owner, refresh time, source system, and known caveats.
- Separates cosmetic dashboard issues from problems that can change a business decision.
- Returns a trust summary, risks, questions for the owner, and fixes to make before sharing.
A team opens a dashboard in a meeting, notices a number looks odd, and spends the discussion arguing about whether it is trustworthy.
Run /dashboard-audit before the meeting to identify stale data, unclear definitions, risky filters, and questions for the owner.
För vem
Review dashboard trust, definitions, source freshness, and blocking issues.
Visa skills för denna rollKnow whether product metrics are safe for launch or roadmap decisions.
Visa skills för denna rollCheck revenue dashboards before forecast, pipeline, or leadership reviews.
Visa skills för denna rollVad det gör
Check whether a dashboard is safe to use in a weekly business review.
Find why numbers look wrong, stale, or inconsistent with another source.
Review definitions, filters, and owners before a new dashboard goes live.
Så fungerar det
Share dashboard screenshots, metric definitions, filters, SQL snippets, or exported numbers.
State the decision the dashboard is supposed to support.
The skill checks freshness, definitions, filters, source alignment, and contradictions.
A human confirms the source owner, fixes blocking issues, and decides whether the dashboard can be used.
Indatametoder
Screenshots, exported table, metric definitions, filters, refresh timestamp, or SQL.
Exempel
Dashboard: Weekly Revenue Overview. Decision: leadership will decide whether Q3 pipeline recovery plan is working. Observed: - Revenue chart says bookings are up 18%. - CRM report says commit forecast is down 9%. - Dashboard last refreshed Friday 18:00. - Filter excludes Enterprise region because of a saved view. - Owner listed: RevOps Analytics, but owner left last month. Need: can we use this dashboard in Monday review?
Do not use as the primary decision source yet. The dashboard may be useful for directional context, but two blocking issues can change the leadership decision.
Enterprise is excluded by a saved filter, and the owner is stale. Because Enterprise can materially change bookings and forecast, the dashboard is not decision-ready.
Friday refresh may be acceptable for Monday review only if weekend CRM changes are not material. Confirm refresh schedule and last successful job.
Who owns this dashboard now? Should Enterprise be included? Are bookings and commit forecast intentionally different metrics?
Reset filter, assign owner, refresh data, and add a note explaining bookings vs commit forecast.
Förbättrade mätvärden
Fungerar med
Fungerar överallt
Paste the notes, exports, screenshots, or summaries you already have. The skill works without a connected system.
Connect the relevant support, analytics, CRM, or data tool when you want fresher source evidence.
Vill du använda Dashboard Audit?
Välj hur du vill komma igång.
Installera och kör denna skill lokalt på din dator.
Öppna en terminal på din dator och klistra in detta kommando:
Besök GitHub-repot och följ installationsinstruktionerna i README.
Starta Claude Code och skriv kommandot:
Dashboard Audit
Command: /dashboard-audit
When to use it
Reviews dashboard definitions, freshness, filters, owners, source systems, and obvious contradictions so teams know whether the numbers are safe to use.
What the skill produces
- Explains whether dashboard numbers are decision-ready, stale, inconsistent, or missing context.
- Checks metric definitions, filters, date ranges, owner, refresh time, source system, and known caveats.
- Separates cosmetic dashboard issues from problems that can change a business decision.
- Returns a trust summary, risks, questions for the owner, and fixes to make before sharing.
Inputs to provide
- Dashboard evidence: Screenshots, exported table, metric definitions, filters, refresh timestamp, or SQL.
- Decision context: The meeting, business decision, launch, forecast, or review the dashboard supports.
- Known concerns: Numbers that look wrong, source differences, missing filters, or suspected stale data.
Recommended flow
- Share dashboard screenshots, metric definitions, filters, SQL snippets, or exported numbers.
- State the decision the dashboard is supposed to support.
- The skill checks freshness, definitions, filters, source alignment, and contradictions.
- A human confirms the source owner, fixes blocking issues, and decides whether the dashboard can be used.
Useful result example
Trust level
Do not use as the primary decision source yet. The dashboard may be useful for directional context, but two blocking issues can change the leadership decision.
Blocking issues
Enterprise is excluded by a saved filter, and the owner is stale. Because Enterprise can materially change bookings and forecast, the dashboard is not decision-ready.
Freshness risk
Friday refresh may be acceptable for Monday review only if weekend CRM changes are not material. Confirm refresh schedule and last successful job.
Owner questions
Who owns this dashboard now? Should Enterprise be included? Are bookings and commit forecast intentionally different metrics?
Fix before meeting
Reset filter, assign owner, refresh data, and add a note explaining bookings vs commit forecast.
Guardrails
- Keep user-provided numbers, dates, tool names, commands, IDs, URLs, and rules intact.
- Do not invent a source, metric, owner, decision, or risk that is not present in the supplied material.
- Clearly mark what a human must confirm before publishing, changing a tool, or making a business decision.
Referensdokument
Dashboard Audit
ElasticFlow editorial instructions for presenting /dashboard-audit in the catalogue.
Purpose
Reviews dashboard definitions, freshness, filters, owners, source systems, and obvious contradictions so teams know whether the numbers are safe to use.
Non-technical presentation
Explain the business problem, what the user provides, what the AI returns, and what a human still needs to confirm. Avoid implementation detail unless the user supplied it.
Catalogue Presentation Method
Every skill should read clearly for a business owner: current painful workflow, better workflow, concrete example, and review checklist.
The page must answer four questions: when to use it, what to provide, what the AI returns, and which human decision remains.