A skill that should be invoked whenever a user wants to build a Dashboard or simple app. This skill is Phase 2 of an e2e process that covers the actual build and testing. For Phase 1 (requirements, layout design, visualization selection), use the dashboard-design skill.
npxskills add mckinsey/vizro--skill dashboard-buildLoading…
Requires Phase 1 spec files from the dashboard-design skill: spec/1_information_architecture.md, spec/2_interaction_ux.md, and spec/3_visual_design.md. If these do not exist, ask the user whether to run Phase 1 first or proceed without specs.
app.py you will create, with uv run <script_name>.py or uv run app.py - this will ensure you use the correct dependencies and versions.sleep, echo, or anything else) in the terminal where the dashboard app is running, even if you started it with isBackground=true. This WILL kill the dashboard process. The dashboard startup takes time - be patient and let it run undisturbed.IMPORTANT: Each step produces a spec file in the spec/ directory to document reasoning, enable collaboration, and allow resumption in future sessions. Create the spec/ directory if it is not already present at the root of the project.
uv run ./scripts/get_model_json_schema.py <model_name> <model_name2> ... where <model_name> is the name of the model you want to get the schema for (prints the full JSON schema for each model to stdout). You can get an overview of what is available by calling the overview script like so: uv run ./scripts/get_overview_vizro_models.py (prints all available model names with one-line descriptions to stdout).Graph model in your dashboard app.uv run <your_dashboard_app>.py CRITICAL: After running this command, DO NOT run ANY other commands in that terminal. The dashboard takes time to start up (sometimes 10-30 seconds)sleep in it. Fix any warnings and even more important errors you encounter. ONLY once you see the dashboard running, inform the user. NEVER run any commands in that terminal after starting the dashboard.spec/3_visual_design.md has an explicit ## Colors section. For AG Grid cell styling (conditional formatting, heatmaps), use from vizro.themes import palettes, colors — never invent hex values. See selecting-vizro-charts skill.kpi_card / kpi_card_reference in Figure model only. Never rebuild as custom charts (exception: dynamic text). See selecting-vizro-charts skill.vm.AgGrid with figure=dash_ag_grid(...) only. Never vm.Table / Dash DataTable, never fake-table with Plotly. See example_ag_grid.py for the two canonical patterns and the Dash-AG-Grid / JS-AG-Grid knowledge mapping.## Interactions section in spec/2_interaction_ux.md.Copy the template from assets/4_implementation.md to spec/4_implementation.md at the project root, fill in the placeholders, and save it BEFORE proceeding to Step 2.
Before proceeding to Step 2, verify against spec files:
spec/1_information_architecture.md, spec/2_interaction_ux.md and spec/3_visual_design.md are implemented if specs existspec/4_implementation.mdThis step is critical for producing bug-free dashboards. Do NOT skip it.
When conducting the below tests, go back to Step 1 to fix any issues you find, then come back here.
Run these validation scripts against your app.py to catch common issues:
uv run ./scripts/validate_colors.py . — Checks for hardcoded colors (color_discrete_map, hex codes, plot_bgcolor) that bypass Vizro theming. Fix any FAIL. If the user explicitly asked for custom colors, add --custom-colors-requested to skip app.py color checks.uv run ./scripts/validate_aggregation.py . — Checks that bar/line charts use pre-aggregated data via @capture("graph"), not raw detail rows passed to inline px.bar/px.line. Fix any FAIL.Navigate the running dashboard to catch errors that code review alone cannot find: (1) console errors on launch, (2) callback errors on page navigation, and (3) callback 500s when actions fire — these only surface when the user actually clicks an interactive source, never on load.
Determine which browser automation tool is available:
Playwright MCP tools available? → Use them directly to navigate, click pages, and check console. No Playwright MCP? → Install the Python package, then write a test script. Use uv pip install playwright && uv run playwright install --with-deps chromium — the --with-deps flag installs OS libraries Chromium needs and is required on slim Linux base images (Docker, CI runners, devcontainers) where the plain install will fail at launch with missing-shared-library errors. It is safe on macOS/Windows too. Skip the install if Chromium is already on disk — it is a ~170 MB download.
Approach — batch errors, don't loop one-at-a-time. Walk every page and exercise every action in one pass, collecting all errors (console, network 500s, callback failures, server tracebacks in the dashboard process output) into a single list. Then fix all of them in one batch of edits, restart the dashboard once, and re-walk. The trap to avoid: find-one-error → fix → restart → find-next-error → fix → restart. Each restart costs ~30–60 s and you will hit your time budget long before the dashboard is clean.
Using your chosen tool, perform these checks in a single walk:
http://localhost:8050).app.py contains any actions= (cross-filter, cross-highlight, drill-through, export), exercise each one in the same walk: grep your app for actions= and for every match, click the corresponding source (a point on the scatter, a bar, a row in the AgGrid, the export Button, etc.). For each, record:
Callback error updating ... messages,_dash-update-component,show_in_url=True, target filter changed, highlight applied, file downloaded, etc.).app.py in) for server-side tracebacks — these surface the root cause when the browser only shows a generic callback error.Important things to check:
Copy the template from assets/5_test_report.md to spec/5_test_report.md at the project root, fill in the placeholders, and save it to complete the project.
validate_colors.py, validate_aggregation.py) both PASSactions= in app.py has been clicked in the browser and produced its intended effect with no callback 500spec/ directory| Reference | When to Load |
|---|---|
| selecting-vizro-charts skill | Colors, KPI cards, custom charts, Plotly conventions |
| writing-vizro-yaml skill | YAML syntax, component patterns, data_manager, pitfalls |
| wiring-vizro-actions skill | Cross-filter, cross-highlight, drill-through, export |
| data_management.md | Static vs dynamic data, caching, databases, APIs |
| custom_charts_guide.md | Implementing custom @capture("graph") charts |
| example_app.py | Starting template for dashboard implementation |
| example_ag_grid.py | Canonical AG Grid patterns — read BEFORE writing any vm.AgGrid |
| validate_colors.py | Automated check for hardcoded colors in app.py |
| validate_aggregation.py | Automated check for pre-aggregation in bar/line charts |
Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
Set up and use 1Password CLI (op). Use when installing the CLI, enabling desktop app integration, signing in (single or multi-account), or reading/injecting/running secrets via op.
CLI to manage emails via IMAP/SMTP. Use `himalaya` to list, read, write, reply, forward, search, and organize emails from the terminal. Supports multiple accounts and message composition with MML (MIME Meta Language).
Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
Set up and use 1Password CLI (op). Use when installing the CLI, enabling desktop app integration, signing in (single or multi-account), or reading/injecting/running secrets via op.
CLI to manage emails via IMAP/SMTP. Use `himalaya` to list, read, write, reply, forward, search, and organize emails from the terminal. Supports multiple accounts and message composition with MML (MIME Meta Language).