review-my-dashboard

review-my-dashboard

The reviewer who knows dashboards fail between correct parts: every measure can be right, every query clean, and the assembled surface still tells the room a lie.

When to use

Fire when a dashboard, report, or workbook is about to ship, get shared, or get trusted — and what needs checking is the assembled surface: measures, filters, interactions, totals, drill paths, defaults, encodings, titles. Works from what you provide as text — DAX/M/LookML definitions, a tool export (PBIT/TWB/LookML contents), filter configurations, described or screenshotted visuals — plus a structured walkthrough for what isn't on paper. Do NOT fire on the code behind ONE number (review-my-query — this assumes the parts and reviews the assembly), on a number already wrong in production (triage-my-number), on the experiment/forecast a visual displays (audit-my-experiment / audit-my-forecast), or to rehearse defending the dashboard (defend-my-number). This reviews the surface; it does not review code line-by-line, diagnose, audit results, or rehearse.

The trap this exists to beat

Asked to "QA the dashboard," a capable model does one of two wrong things. It reviews the SQL and measures it can see — all individually correct — and blesses the whole; but dashboards fail in the assembly layer: the visual-level filter that quietly changes a measure's meaning, the total row summing a distinct count (non-additive — the total is a lie even though every row is true), the FY date default that silently excludes the current quarter, the "live" label over a March extract, the drill that shifts grain mid-path. Or it QAs usability — layout, color, load time — when the question was truth. Either way the room gets a confident surface whose parts are right and whose whole is wrong. This skill reviews the assembly as its own artifact, against the locked contracts, and grades what it finds by what ships wrong.

The loop

1. Scope the surface. Which dashboard/pages, as-of when, built on which extracts/datasets, serving which decision. Inventory what's reviewable as text (definitions, configs, exports, screenshots) and what isn't — the not-reviewable list survives into the verdict as the coverage boundary.
2. Pull the contracts. kpi-contract.md for every metric the surface displays; a displayed metric with NO locked contract is itself a finding (Blocking if it headlines). The surface is reviewed against what the numbers are CONTRACTED to mean, not against what looks plausible.
3. Walk the semantic layer (the engine — references/dashboard-engine.md). Per measure: definition vs contract; additivity (does the total/subtotal operation make sense for THIS measure — distinct counts, ratios, and averages don't sum); filter interactions (page/visual/report-level filters and what each does to each measure's meaning); time intelligence (YTD vs rolling vs calendar, the timezone and refresh-time of "today"); drill paths (does grain shift; do measures survive the shift).
4. Walk the state layer. Default filter values vs what the title claims (defaults that exclude are findings); extract/refresh staleness vs the freshness the surface implies; RLS — which numbers change by viewer, and is that stated; bookmarks/default views that diverge from what was reviewed.
5. Walk the presentation layer. Axis truncation and dual-axis implication; color scales that exaggerate; sort ambiguity; the title test — does each title/label/annotation claim ONLY what its visual's data supports (a trend title over a cherry-picked window fails); units and rounding consistent with the contract.
6. Grade, emit + thread. Findings graded Blocking / Latent / Advisory (ships-wrong now / bites-later / costs-trust) with evidence cites and fix DIRECTION only. Write dashboard-review.md (template: references/dashboard-review.md); a would-have-shipped lie stopped gets its catches.md line; offer the kb(review-my-dashboard) commit. Then stop — the dashboard edit is yours.