/review-my-dashboard

name: review-my-dashboard
description: Use when a finished thing — a source, a result, code, or the record — is about to be trusted or consumed; the gate fires before the work leans on it. A dashboard or report — the assembled surface — needs reviewing before it ships. The failures live in the ASSEMBLY, not the SQL — non-additive totals (summed distinct counts, averaged averages), measure-filter interactions, default filters that silently exclude, stale extracts, titles and axes that claim what the data doesn't. Reviews the definitions and configuration you provide (DAX/M/LookML, exports) as text against the locked contracts. Detects: "review my dashboard", "check this report before we share it", "dashboard QA". Within this family: the code behind ONE number is review-my-query — this reviews what the assembly does to correct parts; the record is kb-reconcile. Never opens a live tool, never edits the dashboard.
allowed-tools: Read, Write

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.

The signature output: the assembly review

A findings register where the unit of review is the surface, not the parts — each finding placed in its layer (semantic / state / presentation), graded by ship-impact, tied to the contract it violates, with the coverage boundary stating what couldn't be seen from text. Taxonomy and the worked example live in `references/dashboard-engine.md`.

Bright lines (non-negotiable; inherits groundwork's read-only line)

• **Never open, connect to, or refresh a live BI tool.** The review is of definitions, configurations, and exports as text — what cannot be reviewed from text is named, not guessed.
• **Never edit the dashboard or write the corrected measure.** Finding + fix direction; a tiny illustrative fragment at most. The fix is yours.
• **Additivity is checked per measure, every time.** A correct measure with a wrong total is a Blocking finding — the total is what the room reads.
• **The title test is part of the review.** Words on the surface ar