# creating-good-dashboards
Adopt this skill: https://proskills.md/skills/other/data-goblin-power-bi-agentic-development-plugins-dashboards-skills-creating-good
Page: https://proskills.md/skills/other/data-goblin-power-bi-agentic-development-plugins-dashboards-skills-creating-good
This document is the public skill bundle for that page. It contains SKILL.md and every helper file the catalog carries. No login is required.
## File: plugins/dashboards/skills/creating-good-dashboards/SKILL.md
size: 7578
upstream: https://github.com/data-goblin/power-bi-agentic-development/blob/main/plugins/dashboards/skills/creating-good-dashboards/SKILL.md
````text
---
name: creating-good-dashboards
description: >
Design and revise Claude Dashboards that people trust and can read at a glance, and handle the comments people
leave on them. Use this skill whenever you create, restyle or change a dashboard, answer or act on a dashboard
comment (including @Claude mentions in a comment thread), or the user asks for a dashboard to look better,
cleaner or more professional. Covers comment etiquette (never resolve comments yourself, reply in short
bullets), visual style following Stephen Few and Edward Tufte, Shneiderman's overview-zoom-details layout,
actionable "do next" guidance, and avoiding generic AI-generated design.
---
# Creating good dashboards
A dashboard is read in seconds and shared with people who did not build it. Two things decide whether it
works: the people commenting on it stay in control of the conversation, and every pixel helps someone see the
answer.
## Comments
Comments are how people review a dashboard together. The person who raised a comment decides when it is done.
- **Never resolve a comment yourself**, even after you made the change it asked for, and even where other
instructions (such as the Dashboard type's own) say to reply and resolve. Reply, and leave it open for its
author to check and resolve. A thread you resolve disappears from their view before they have seen whether
the change is right
- **Reply in a few short bullets**: what you changed, where, and anything you could not do. No preamble, no
restating the request, no sign-off
- **Ask in the thread** when a comment is ambiguous, instead of guessing and rewriting the dashboard
- **One change per comment**: do what the comment asks; propose other improvements in a reply rather than
slipping them in
```text
- Added a dotted grey line for August 2021 to the monthly chart
- Same-days comparison now matches the KPI card (Jan 1 to Aug 19)
- Could not split by region: the model has no region on order lines
```
## Visual style
Follow Stephen Few (dashboards for monitoring at a glance) and Edward Tufte (maximise the data, minimise
everything else).
```yaml
one screen: the whole answer fits one view without scrolling; a headline sentence states it
hierarchy: most important number top left; KPIs first, then trends, then breakdowns, then detail
kpis: each KPI shows its value, a target and a trend (sparkline), and says the period and unit
data-ink: no 3D, no shadows, no gradients, no heavy borders or boxes; light gridlines or none
colour: greys for context, one accent colour for what needs attention; red and green only for status,
and never as the only signal (colour blindness)
labels: label lines and bars directly; drop legends where a direct label works
charts: bars and lines over pies, gauges and donuts; bullet graphs over gauges for value against target;
sorted bars for rankings; small multiples over one cluttered chart; a calendar heatmap for a
daily measure over a year. Exception: when the user's existing reports or apps already use a
gauge or dial for this metric, reuse that exact visual so the two stay recognisable
scales: bar axes start at zero; same scale across small multiples; no dual axes
numbers: round to what the reader needs (2.3M, not 2,312,947.21); align right; use the model's formats
text: plain titles that say what the chart shows ("Late penalties by territory, 2025 YTD")
interaction: every visual crossfilters the others; show active filters and a way to clear them
honesty: mark partial periods, state missing targets, and say when a number is a dashboard-only
calculation rather than a model measure
```
## Overview first, zoom and filter, details on demand
Lay the dashboard out along Ben Shneiderman's information-seeking mantra, top to bottom, so the reader moves
from "how am I doing" to "why" to "this one case" without leaving the page.
```yaml
overview: the headline, the KPI row and one picture of the whole history (a year heatmap or a long trend);
every mark the reader may want to inspect is visible here at rest
zoom: a small set of period chips (7, 30, 90, 365 periods, or the business's own grain) that re-query every
KPI and dim what falls outside the window in the overview, instead of a date picker
filter: clicking a mark (a bar, a heatmap cell, a row) filters or selects; the active filter is shown in one
place with a way to clear it
details: a detail panel or tooltip shows the selected item's own values next to the typical value for the
current window ("8h 16m, +1h 17m vs median"); nothing important lives only in a tooltip
```
## Actionability
A dashboard earns its place when the reader knows what to do next. Monitoring alone is not enough.
- Give it a "do next" block: two or three ranked actions, each with the expected effect and the evidence behind
it ("Orders shipped within 2 days: +18% repeat rate, 340 customers"). Rank by the size of the effect in the data
- Derive actions from drivers the data shows: compare the KPI across a lever the reader controls (time of day,
day of week, channel, account) and state the difference; never give generic advice the data does not support
- Show the sample size behind every driver, and say when it is a dashboard-only calculation
- Status words and colours ("on track", "short") need a stated target from the model or the user; without one,
compare to a prior period and say so
- Put the action next to the KPI it moves, not in a separate notes section
## Avoid AI-generated design
Generated dashboards drift to a few recognisable looks. Do not use them unless the user asks for them:
```yaml
palettes: warm cream with a serif display and a terracotta accent; near-black with one acid-green or
vermilion pop; purple-to-blue gradient heroes
layout: everything centred; broadsheet hairline rules with dense columns; numbered 01/02/03 markers on
content that is not a sequence; big-number tiles that are not the point of the page
components: rounded-lg and the same shadow on every block; an accent bar down the side of rounded cards;
emoji as section markers or icons
type: Inter or Space Grotesk picked as the safe default
copy: subtitles, taglines, eyebrows and helper text that repeat the title; every word must help the
reader act
```
What to do instead:
- **The user's direction wins**, including when they ask for one of these looks
- **Reuse the user's existing visual system first**: their other dashboards, apps, themes or design tokens,
down to the exact colours, fonts and chart components. A dashboard that matches what they already use reads
as theirs; a fresh template reads as generated
- **Otherwise derive the look from the subject**: its units, scales and conventions (durations and times of day
for scheduling, fiscal periods for finance), with deliberately chosen neutrals and one accent
- **Design both light and dark** from one token set unless the user commits to one; check contrast in both
- **Style every native control** (selects, scrollbars, focus rings, buttons) to match; browser defaults look
unfinished
Before sharing, look at the dashboard as its reader would: can they say in five seconds whether things are on
track, what to do next, and where to look for detail? If not, remove something before adding anything.
````
## File: README.md
upstream: https://github.com/data-goblin/power-bi-agentic-development/blob/main/README.md
````text
power-bi-agentic-development
The best source for Power BI AI skills and agentic development resources in one marketplace
Teach AI agents like Claude Code or GitHub Copilot Power BI and Microsoft Fabric
> [!WARNING]
> These skills are under active development with a weekly release cadence, so expect regular renaming and restructuring.
>
> **Versions 26.26 through 26.38 are a deliberate breaking transition.** Skills may be
> consolidated, renamed, removed, or made less automatic between weekly releases in this range.
> Pin **26.25 or earlier** if you need the pre-transition skill structure and behavior; do not
> assume compatibility from one transition release to the next.
---
### What is agentic development?
- *Agentic development* is when you use agents to help you build, manage, and optimize artifacts and software. This includes semantic models, reports, and the things around them, like workspaces, deployment pipelines, and also processes.
- A *marketplace* hosts *plugins* that you can install. Plugins are a collection of resources that help coding agents perform better. They are typically special instruction files and scripts. Plugins can contain skills, subagents, hooks, and MCP servers focused on special topics or tasks.
- This marketplace is focused on everything to help your agent work well with Power BI and Fabric: Power BI skills, Fabric skills, subagents, and hooks for coding agents. Read further for more information.
## Installation
Here's how you get started in Claude Code; run this in the terminal to get the marketplace:
```bash
claude plugin marketplace add data-goblin/power-bi-agentic-development
```
### Example: Using the pbir-cli with the skills
[Click here for a YouTube walkthrough](https://www.youtube.com/watch?v=acHDorTi62U)
[](https://www.youtube.com/watch?v=acHDorTi62U)
### Claude Code
Add the marketplace, then install plugins via `/plugin` and navigating to the installed marketplace.
 |
 |
| Install plugins from the marketplace |
Enable marketplace auto-update |
Alternative; add plugins via command line:
```bash
claude plugin install goblin-mode@power-bi-agentic-development
claude plugin install tabular-editor@power-bi-agentic-development
claude plugin install pbi-desktop@power-bi-agentic-development
claude plugin install pbip@power-bi-agentic-development
claude plugin install semantic-models@power-bi-agentic-development
claude plugin install reports@power-bi-agentic-development
claude plugin install paginated-reports@power-bi-agentic-development
claude plugin install custom-visuals@power-bi-agentic-development
claude plugin install fabric-cli@power-bi-agentic-development
claude plugin install fabric-admin@power-bi-agentic-development
claude plugin install databricks-cli@power-bi-agentic-development
claude plugin install fabric-data-app@power-bi-agentic-development
claude plugin install etl@power-bi-agentic-development
claude plugin install dashboards@power-bi-agentic-development
```
### Copilot CLI
The standalone [Copilot CLI](https://docs.github.com/en/copilot/how-tos/copilot-cli) supports plugin installation from GitHub repos. Copilot CLI reads the same `.claude-plugin/marketplace.json` manifest this repo uses, so the marketplace and child-plugin layout works without modification.
Windows long paths
TMDL files have a problem with repository-relative paths over 260 characters. Windows' legacy MAX_PATH blocks `git clone` from writing them unless long path support is enabled at both the OS and git level. Without this, `copilot plugin install` aborts with `Filename too long`.
Check [`useful-stuff/agent-scripts/enable-windows-longpaths.ps1`](useful-stuff/agent-scripts/enable-windows-longpaths.ps1) as an example of a script you can run from an elevated ps environment to enable long paths; there are other routes to do this that you can find online, too... just ask Copilot. A reboot is recommended after the registry change. This is a Windows OS limitation, documented at [Maximum Path Length Limitation](https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation).
See also the below `git config` command:
```powershell
git config --system core.longpaths true
```
Additional installation instructions
This repository is an [Anthropic-format plugin marketplace](https://code.claude.com/docs/en/plugin-marketplaces) (a set of plugins), not a single distributable plugin, so the root `.claude-plugin/` contains only `marketplace.json`. Two documented install paths work:
**1. Register the marketplace once, then install named child plugins. Example:**
```bash
copilot plugin marketplace add data-goblin/power-bi-agentic-development
copilot plugin install tabular-editor@power-bi-agentic-development
```
**2. Or install a single plugin directly from its subdirectory, no marketplace registration needed. Example:**
```bash
copilot plugin install data-goblin/power-bi-agentic-development:plugins/pbip
```
Both forms are documented in the [Copilot CLI plugin reference](https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-plugin-reference) and the [plugins how-to](https://docs.github.com/en/copilot/how-tos/copilot-cli/customize-copilot/plugins-finding-installing). Inside an interactive Copilot session, `/plugin install PLUGIN-NAME@MARKETPLACE-NAME` is the equivalent of (1). The bare `copilot plugin install data-goblin/power-bi-agentic-development` (no qualifier) will not install anything useful, because the root is a marketplace catalog, not a plugin.
Verify installation in Copilot CLI
Inside Copilot CLI:
```
/env # Loaded instructions, MCP servers, skills, agents, plugins, LSPs, extensions
/plugin list # Installed plugins
/skills list # Available skills
/skills info pbip # Details for a specific skill
/agent # Browse installed agents
```
Compatibility notes
- **Skills** load identically; Copilot CLI reads `skills//SKILL.md`.
- **Agents** use the `*.agent.md` extension required by Copilot CLI's documented convention. Claude Code matches any `*.md` file in `agents/`, so the dual extension works in both tools.
- **MCP servers** load from `.mcp.json` (plugin root) or `.github/mcp.json`. The plugins in this repo do not currently ship MCP servers.
- **Hooks** ship twice. Claude Code reads `hooks/hooks.json` (with per-hook `if` path filters). Copilot CLI reads `.github/plugin/plugin.json`, which points it at `hooks/copilot-hooks.json`: the same scripts, wired with explicit `bash` and `powershell` commands so a Windows host without Git Bash on `PATH` gets a clean no-op instead of a failed launch. Copilot has no `if` filter and denies a tool call on any non-zero PreToolUse exit, so every script also re-applies its own path and command filter
````