dashbook
Use / Engineer

Engineer.

Build Dash.fi UI in any stack. Dashbook exposes the design system three ways: a Claude Code plugin with skill + slash commands + MCP, a remote MCP for other clients, and a static JSON / SVG API for everything else.

1. Install

The fastest path: install the plugin and let Claude Code wire everything.

bash 
# In Claude Code (per-user)
/plugin marketplace add trlmkb/dashbook
/plugin install dashbook@dashfi

# Verify
/mcp                          # "dashbook" should appear, connected
/dashbook-component button    # fetches Button anatomy from MCP

Full setup matrix (Claude Code · claude.ai · Desktop · Claude Design) lives at /developers/install.

2. Workflow

The canonical loop when building a screen.

bash 
# 1. Find the right component
product_list_components({ category: "Inputs" })

# 2. Get full anatomy (dimensions, tokens, variants, props)
product_get_component({ slug: "button" })

# 3. For a non-Svelte stack, get the stack-specific port
product_port_to({ slug: "button", stack: "react" })

# 4. Resolve a token to a hex value
product_get_token({ name: "brand" })   # → { light: "#2B605C", dark: "#5BB8B0" }

The skill activates automatically on Dash.fi keywords. If you're hitting it manually, prefix your request with "Use the Dashbook product design system" so the agent loads context.

Clients that browse a catalogue instead of calling tools can also read MCP resources — dashbook://components, dashbook://components/{slug}, and dashbook://foundations/{slug} — same data, resources/list + resources/read. Full connector setup (Claude Code CLI, claude.ai custom connector, discovery via llms.txt / the ARD manifest) is documented at /developers/mcp.

3. Build to spec

Every component has a structured anatomy: dimensions, tokens, variants, sizes, props, composition rules, non-features, porting checklist.

  • Dimensions: exact pixel values (height, padding, radius). No "looks about right."
  • Tokens: resolved hex values in both light + dark mode. Token name + literal hex next to each other so the port is unambiguous.
  • Composition: how the component is assembled from sub-parts. E.g. Button = root + label + optional icon.
  • Non-features: what the component explicitly does NOT do. Saves you from "can I add an icon prefix to Input?" (no — wrap it differently).
  • Props: typed props table with defaults + nullable flags.
  • Porting: stack-specific checklist (React / RN / HTML+CSS / Vue).
4. Non-Svelte stacks

Tokens, components, and the port-to recipes work the same way regardless of stack. The lib is Svelte; the design system is the design system.

See /developers/from-another-stack for the full guide on vanilla CSS tokens, font loading, component port recipes for React / React Native / HTML+CSS / Vue.

5. No MCP? Hit the JSON API

Every component anatomy and every foundation token is available as static JSON. CORS open, 24h cache, no auth, no SDK.

bash 
# No MCP client? Hit the JSON API directly:
curl https://dashbook.vercel.app/api/components.json                # catalogue
curl https://dashbook.vercel.app/api/components/button.json         # one component
curl https://dashbook.vercel.app/api/foundations/color.json         # tokens (light + dark)
curl https://dashbook.vercel.app/api/foundations/typography.json    # type system + webDelivery URLs
curl 'https://dashbook.vercel.app/api/logo/wordmark/jade?format=svg&size=400'  # wordmark

These work for any client — agents, crawlers, archives, link unfurlers, doc-search indexers. Same shape as the MCP tools return.

6. Reporting bugs

Found a component anatomy that doesn't match the source? An MCP tool that returns the wrong shape? A token that drifted?

  • Issue on GitHub: trlmkb/dashbook/issues
  • Slack: #dashbook (or DM the maintainer)
  • Quick fix yourself: PRs welcome. The spec files at src/lib/specs/ are the single source of truth — fixing one updates docs + MCP + JSON API simultaneously.