Specifies what questions a dashboard must answer and the metrics, visualizations, filters, and data sources it needs, so data teams build something that informs decisions rather than displaying numbers.
SkillScore78Maintained
Automatic
◆Product Management pack
Last verified 8/18/2026
What it changes
Passed 18 of 23 test cases with the skill, and 13 of 23 without it.
Without skill57%
With skill78%
Checks it passed that the model alone missed
Includes a section for Appendix.
Includes a section for Open Questions.
Includes a section for Acceptance Criteria.
and 6 more in the full report
6 fixed12 passed either way4 still failing1 broke
Pass-rate lift
+22 pp
Tokens
+65%
Agent turns
0%
Response time
+50%
Model gemini-3.6-flashMeasured 8/18/2026v118 of 23 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 6
Prompt
Our executive team needs a formal dashboard specification to monitor user retention and plan upgrades across our B2B platform. Please prepare a comprehensive requirements spec for our analytics engineers. It should detail the business questions to answer, intended audience, key metric formulas, chart selections, dimension filters, data sources with refresh rates, and access permissions.
What was checked, without and with the skill
Checked
Without skill
With skill
Includes a section for Alerts and Thresholds.
Missed
Passed
Includes a section for Open Questions.
Missed
Passed
Includes a section for Appendix.
Missed
Passed
case-01 · gemini-3.6-flash · 8/18/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md63 lines3 files
Dashboard Requirements
A dashboard requirements document specifies what questions a dashboard should answer, what metrics it displays, and how data should be visualized. Clear requirements help data teams build dashboards that actually inform decisions rather than just displaying numbers.
When to Use
When requesting a new dashboard from data/analytics teams
To define KPI tracking for a product, feature, or team
When formalizing ad-hoc reporting into a persistent dashboard
Before quarterly planning to specify what visibility you need
When onboarding stakeholders who need self-serve analytics
When NOT to Use
You need the event tracking that feeds dashboards -> use measure-instrumentation-spec; instrument first, visualize second
You are designing an experiment readout, not a standing dashboard -> use measure-experiment-design and measure-experiment-results
You want OKR progress scored at cycle close -> use measure-okr-grader
The questions the dashboard should answer are not yet agreed -> frame outcomes first with foundation-okr-writer or define-problem-statement
Instructions
When asked to specify dashboard requirements, follow these steps:
Define the Purpose
Start with the questions this dashboard should answer, not the charts it should show. What decisions will this dashboard inform? A dashboard without clear purpose becomes a vanity metrics display.
Identify the Audience
Specify who will use this dashboard, how often, and in what context. An executive weekly review has different needs than a team's daily standup board.
Specify Key Metrics
For each metric, document: name, business definition (in plain language), calculation formula, data source, and baseline/target values. Ambiguous metrics lead to misaligned dashboards.
Design Visualizations
Recommend chart types based on what the data should communicate. Time trends need line charts; comparisons need bar charts; compositions need pie/treemaps. Include dimension breakdowns.
Define Filters and Segments
Specify what drill-downs users need: date ranges, user segments, product areas, geographic regions. Anticipate the "slice and dice" questions users will ask.