ds-bridge is a Claude Code plugin that keeps design and code on the same system — token-aware linting, drift detection, handoff QA, parity, and design-to-code. Every slash command is a thin wrapper over the bundled CLI, so anything you run in Claude you can also run in CI.
Ten slash commands ship in this plugin, all namespaced /ds-bridge:<name>. Most run a matching CLI command and interpret its --format=json output — with a --format=term default for humans. Two are different: dashboard opens the rendered HTML report instead, and figma-impl orchestrates several CLI calls around the Figma MCP connection. The first five are the daily drivers; the rest are the v2 additions.
| Slash command | CLI underneath | What it does |
|---|---|---|
/ds-bridge:ds-lint | ds-bridge lint | Find hardcoded values that should be design tokens; --fix rewrites exact matches only, never near-misses. |
/ds-bridge:token-check | ds-bridge tokens check | Detect drift between the token source and built outputs — stale, missing, and orphan values. |
/ds-bridge:dashboard [--setup] [path] | ds-bridge report [--view] [--artifacts] | Render the offline, self-contained HTML dashboard from history.jsonl and open it; --setup composes a persona view — owner, engineering, design, or consumer — from the same history. |
/ds-bridge:handoff-qa | ds-bridge handoff | Score a Figma frame’s pre-handoff readiness 0–100 against the threshold; optionally posts one Figma comment. |
/ds-bridge:parity-audit | ds-bridge parity | Build the Figma ↔ code parity matrix — missing-in-code, missing-in-figma, and prop-mismatch rows. |
/ds-bridge:figma-impl | ds-bridge registry resolve | Implement a Figma frame using only registry components and exact tokens — anything unresolved is reported as a gap, never invented. |
/ds-bridge:a11y-check | ds-bridge a11y | Audit token-level WCAG contrast over semantic color pairings across every mode, and surface the failing ones. |
/ds-bridge:impact | ds-bridge impact | Detect breaking Figma library changes since the last snapshot and map them to the code that uses them. |
/ds-bridge:ds-changelog | ds-bridge changelog | Generate an audience-segmented changelog from git log, labeled Figma versions, and token changes. |
/ds-bridge:ds-docs | ds-bridge docs | Generate component MDX pages plus an llms.txt summary from the saved registry and tokens. |
Exit codes are uniform: 0 clean / pass · 1 findings / below-gate · 2 usage or config error. The two generators — ds-changelog and ds-docs — only ever exit 0 on success or 2 on error; they have nothing to fail a gate on.
dashboard still opens the rendered HTML report — but which artifacts it renders is now yours to compose. The ds-bridge dashboard group manages that selection. It is CLI-only — there is no slash wrapper for the individual commands (the slash surface stays ten); instead /ds-bridge:dashboard --setup drives dashboard set for you. Reach for these directly in CI or scripts.
| CLI command | Exit codes | What it does |
|---|---|---|
ds-bridge dashboard list | 0 · 2 | Print the artifact catalog — id, title, persona tags — with a marker on the ones the current config enables. |
ds-bridge dashboard setup | 0 · 2 | Interactive wizard: pick a preset, optionally customize, and write the choice to .ds-bridge.json. Needs a TTY. |
ds-bridge dashboard set | 0 · 2 | Non-interactive equivalent — --view <preset> or --artifacts <a,b,…> (mutually exclusive). CI-safe; it is what the wizard calls. |
ds-bridge dashboard add | 0 · 2 | Add one artifact to the persisted list, materializing the active preset into an explicit list first. Idempotent. |
ds-bridge dashboard remove | 0 · 2 | Remove one artifact from the persisted list, materializing the preset first. Idempotent — removing an absent one is a no-op. |
ds-bridge badge | 0 · 2 | Render the system score — a weighted blend of drift, lint, readiness, and contrast replayed from run history — as a self-contained SVG badge for your README. |
Two hooks ship in hooks/hooks.json. Both are fail-quiet — they always exit 0 and never block your workflow.
PostToolUse (matcher Write|Edit) lints just the file you wrote or edited, on a ≤ 1.5 s budget. On findings it adds a one-line context summary; on clean files, non-lintable files, errors, or a timeout it exits silently.SessionStart runs a cheap freshness probe: if your token source changed since the last check — or was never checked — it nudges you to run /ds-bridge:token-check. Otherwise it stays silent, and it never spawns the linter or the CLI.ds-bridge keeps project state in your repo, where it’s PR-reviewable, and keeps rebuildable caches out of it. The .ds-bridge/ directory is meant to be committed.
<project>/.ds-bridge/
├── registry.json # component registry (schema-versioned, stable diff order)
├── history.jsonl # one record per lint/drift run — feeds the dashboard trends
├── docs/ # generated component MDX + llms.txt (ds-docs output)
└── reports/
└── dashboard.html # latest self-contained HTML report (offline, no CDN)Rebuildable caches — the Figma version cursor and the REST cache — live under CLAUDE_PLUGIN_DATA (~/.claude/plugins/data/<id>/), which survives plugin updates. ds-bridge never writes to CLAUDE_PLUGIN_ROOT, which is ephemeral across those updates.
Your dashboard view lives in the project’s .ds-bridge.json, alongside the other committed config, through one of two mutually exclusive keys:
dashboard_view — a persona preset, one of owner, engineering, design, consumer, or everything (the default when nothing is set).dashboard_artifacts — an explicit ordered list drawn from drift-trend, lint-summary, readiness, parity, a11y, and impact. Set this when a preset isn’t quite your view.The two keys are mutually exclusive — set one, not both, or you get a config error. Both are written for you by ds-bridge dashboard set or the --setup wizard, which validate ids and keep the diff minimal; hand-editing is discouraged.
Install the plugin, then walk a real workflow end to end — both take a couple of minutes.