Compose a dashboard for your role

What you’ll learn

One repository, many readers. The people who fix things — engineers and designers — want lists: which lint rules fired, which frames aren’t ready, where the parity grid has holes. The people who fund things — managers — want trends: is drift going down, is contrast holding, is adoption climbing toward its target. And the people who consume the system need a third thing: what is safe to build on, and when does it break. There is one history under .ds-bridge/, and many lenses onto it. You pick a persona view, and from then on ds-bridge report renders your dashboard — without changing anyone else’s.

ds-bridge models the design-system bridge as six personas: three on the producer side (who own the library) and three on the consumer side (who build products with it), plus an everything escape for an unconfigured repo.

The six personas + everything, and the 31-artifact catalog each draws from
The persona-first --setup wizard, and the non-interactive dashboard set
Saved, named dashboards — committed for the team or kept personal
Three render targets from one selection: HTML, terminal, and a published site

Setup

You’ll need the ds-bridge plugin (Getting started covers install and the preferences dialog) and a project you’ve run ds-bridge in at least once, so there’s a .ds-bridge/history.jsonl to render. No Figma token is required to pick a view — that’s purely a preference.

# Render the dashboard with whatever view is configured (everything, by default).
ds-bridge report

Steps

Meet the 31 artifacts. Run dashboard list to see the whole catalog — every panel a dashboard can show, its id, and which of the six personas tend to care about it. With no view set, everything is on:

View: everything (default)
┌────┬────────────────────────┬────────────────────────┬───────────────────────────────────────────┐
│ on │ id                     │ title                  │ personas                                  │
├────┼────────────────────────┼────────────────────────┼───────────────────────────────────────────┤
│ ✓  │ system-score           │ System score           │ all six                                   │
│ ✓  │ drift-trend            │ Token drift            │ ds-manager, ds-engineer                   │
│ ✓  │ lint-summary           │ Lint violations        │ ds-engineer, product-engineer             │
│ ✓  │ readiness              │ Handoff readiness      │ ds-designer, product-designer, product-manager │
│ ✓  │ parity                 │ Component parity       │ all six                                   │
│ ✓  │ a11y                   │ Contrast (a11y)        │ ds-designer, ds-manager, ds-engineer, product-designer │
│ ✓  │ impact                 │ Change impact          │ ds-engineer, product-engineer             │
│ ✓  │ adoption-trend         │ Adoption trend         │ ds-manager, product-manager, product-engineer │
│ ✓  │ import-coverage        │ Import coverage        │ ds-manager, product-manager, product-engineer │
│ ✓  │ leaderboard            │ Adoption leaderboard   │ ds-manager, product-engineer              │
│ ✓  │ library-health         │ Library health         │ ds-designer, ds-manager, ds-engineer, product-designer │
│ ✓  │ breaking-calendar      │ Breaking calendar      │ ds-manager, product-designer, product-manager, product-engineer │
│ ✓  │ change-frequency       │ Change frequency       │ product-designer, product-manager         │
│ ✓  │ targets                │ Targets / SLAs         │ ds-manager, ds-engineer, product-manager, product-engineer │
│ ✓  │ parity-trend           │ Parity trend           │ all six                                   │
│ ✓  │ component-health       │ Component health       │ ds-designer, ds-engineer, product-designer │
│ ✓  │ library-health-trend   │ Library health trend   │ ds-designer, ds-manager                   │
│ ✓  │ migration-checklist    │ Migration checklist    │ ds-engineer, product-engineer             │
│ ✓  │ score-velocity         │ Score velocity         │ ds-manager, product-manager               │
│ ✓  │ ownership-leaderboard  │ Ownership leaderboard  │ ds-manager                                │
│ ✓  │ audience-changelog     │ Changelog by audience  │ product-designer, product-manager, product-engineer │
│ ✓  │ frame-implementability │ Frame implementability │ product-designer, product-engineer        │
│ ✓  │ release-readiness      │ Release readiness      │ ds-engineer                               │
│ ✓  │ data-freshness         │ Data freshness         │ all six                                   │
│ ✓  │ consistency            │ Consistency            │ ds-designer, ds-manager, ds-engineer, product-manager │
│ ✓  │ design-debt            │ Design debt            │ ds-designer, ds-manager, ds-engineer      │
│ ✓  │ executive              │ Executive summary      │ ds-manager, product-manager               │
│ ✓  │ library-hotspots-trend │ Library hotspots trend │ ds-designer, ds-manager                   │
│ ✓  │ frame-readiness-trend  │ Frame readiness trend  │ ds-designer, product-designer, product-manager │
│ ✓  │ handoff-pass-rate      │ Handoff pass rate      │ ds-designer, ds-manager, product-designer, product-manager │
│ ✓  │ exceptions-review      │ Recurring exceptions   │ ds-designer, ds-manager                   │
└────┴────────────────────────┴────────────────────────┴───────────────────────────────────────────┘

system-score leads every view — a weighted blend of drift, lint, readiness, contrast, parity, and adoption replayed from history (and a README badge via ds-bridge badge). data-freshness is in every persona too: it’s the trust gauge that tells you whether a green panel is green because it’s clean or green because the check stopped running. The personas column is a hint — you’re free to compose any list you like.

Pick your persona in conversation. The friendliest path is the slash command. Inside Claude Code, run:
```
/ds-bridge:dashboard --setup
```
It asks which of the six personas you are (with a seventh “not sure → everything” escape), confirms your Figma file-key model, saves your choice with ds-bridge dashboard set --view <persona>, and offers to open the result. The persona options are generated live from dashboard list --format=json, so they always match the shipped presets — no hand-authored prose to drift.
Or run the raw wizard. Prefer the terminal? ds-bridge dashboard setup runs the same persona-first flow with no AI in the loop:
```
Pick a dashboard view:
  1) ds-designer
  2) ds-manager
  3) ds-engineer
  4) product-designer
  5) product-manager
  6) product-engineer
  7) everything
View number: 1
Is your DS library file key configured (FIGMA_DESIGN_SYSTEM_FILE / figma_file_key)? (y/N) y
Save the "ds-designer" view? (y/N) y
Saved. Your dashboard view is now "ds-designer".
Default --audience for ds-designer: designers (changelog/digest).
Render it now? ds-bridge report --open
```
A producer persona (ds-designer / ds-manager / ds-engineer) confirms the single library key; a consumer persona (product-designer / product-manager / product-engineer) instead pins their product file under a named product_file_keys alias. Onboarding writes only dashboard_view (a live preset) and any product_file_keys — never your report-style or threshold preferences. The wizard needs a real terminal; in CI, reach for dashboard set.

Read the seven presets. Each persona view is its full intended set, drawn from the 31-artifact catalog (the ids are a stable contract). A DS Manager’s view is the governance cockpit — targets, score-velocity, ownership, freshness; a Product Engineer’s is the fix queue — migration checklist, lint, impact, targets, freshness:

ds-designer       a clean, accessible, in-parity library (readiness, a11y, component-health, hotspots, recurring exceptions …)
ds-manager        the governance cockpit (adoption, targets, score-velocity, ownership, recurring exceptions …)
ds-engineer       tokens↔code + figma↔code parity, the breaking-change source (lint, impact, migration-checklist, release-readiness …)
product-designer  what’s safe to build on (readiness, breaking-calendar, change-frequency, frame-implementability …)
product-manager   delivery + upstream risk vs targets (adoption, breaking-calendar, targets, score-velocity, audience-changelog)
product-engineer  the migration queue (lint, impact, migration-checklist, targets, frame-implementability …)
everything        all 31, in catalog order   (the default)

Set a view without prompts. dashboard set is the non-interactive writer — what the slash command calls under the hood, and what you’d use in CI:
```
ds-bridge dashboard set --view ds-manager
```
dashboard list then shows the resolved selection (the same catalog with only the ds-manager panels on), sourced as project.
Save named dashboards. Beyond your persona, you can save any selection as a named, reusable dashboard under dashboards/. A preset stays live by default (it auto-gains future enrichment); --freeze materializes the exact list:
```
ds-bridge dashboard save exec --view ds-manager     # committed, team-canonical
ds-bridge dashboard save mine --view ds-designer --local   # personal, gitignored
ds-bridge dashboard ls
ds-bridge dashboard load exec       # make "exec" the project default
```
Render one with ds-bridge report --dashboard exec. A saved dashboard can also carry a report_type default and render-scoped score_weights. Describe one in plain language and let the builder draft it: `/ds-bridge:dashboard "score trend
- adoption + breaking calendar, save as exec"` — every id is re-validated by the CLI, so a hallucinated id can never be saved.

Render anywhere — one selection, three targets. The same view drives all of them; --format always wins over a dashboard’s report_type:

ds-bridge report --format html                 # the offline dashboard (default)
ds-bridge report --format md --gate            # a markdown scorecard for PRs / CI
ds-bridge report --format terminal             # a selection-aware text report
ds-bridge report --format site --all-dashboards   # a static site of every dashboard
ds-bridge report --snapshot                    # normalized HTML for committed diffs

The site is path-agnostic, self-contained HTML — publish it to each repo’s own GitHub Pages with the bundled dashboard-pages.yml workflow.

Add or remove one artifact — and meet materialization. dashboard add and dashboard remove tweak a view by a single panel. The first time you do this on top of a preset, ds-bridge materializes it into an explicit list:
```
ds-bridge dashboard add impact
```
```
Your view is now an explicit list and will not auto-gain future preset artifacts.
```
That notice is a promise, not a warning: an explicit list stops tracking the preset, so a future release that adds an artifact to a persona won’t silently grow your list. To follow the preset again, dashboard set --view <persona>.

Result

The ds-bridge HTML dashboard: system score, trends, readiness and next actions — One offline page with the score, trends, per-frame readiness and the gaps to close next.

You can now answer “whose dashboard is this?” with “mine — and yours, from the same history.” You’ve seen the 31-artifact catalog, the seven presets (six personas + everything), saved named dashboards, and three render targets from one selection. A persona persists as dashboard_view; a hand-built list as dashboard_artifacts; a saved-dashboard default as dashboard_default — the three are mutually exclusive, and dashboard set/save/load keep the file honest. A --view/--artifacts/--dashboard flag overrides for a single run.

Troubleshooting

The wizard exits straight away with code 2? dashboard setup only runs in a real terminal. In a script or CI it exits 2 and points you at the non-interactive ds-bridge dashboard set --view <persona> instead.
It says an artifact id is unknown? set, add, remove, and save validate every id against the catalog and exit 2 rather than guess, offering the nearest match (a typo like parityy is answered with parity). Run ds-bridge dashboard list to see the 31 exact ids.
It complains that the dashboard keys conflict? dashboard_view, dashboard_artifacts, and dashboard_default are mutually exclusive — let dashboard set/load rewrite the file cleanly rather than hand-editing.
You set a view but report still shows everything? A --view/--artifacts/ --dashboard flag overrides the project file for that run by design. With no flag, confirm your edit landed with ds-bridge dashboard list.