Primitiv
# Primitiv
**The design system contract keeping teams and agents in sync.**
Retrieval gives you data. Reconciliation gives you truth.
<video src="https://github.com/user-attachments/assets/deb63812-72ea-4651-b248-31d817725d10" controls muted></video>
## The problem
Design-system knowledge is spread across code, Figma, Storybook, and documentation. When those sources drift, people reconcile the differences through experience; AI coding agents often fall back to generic patterns that work but do not belong in the product.
Primitiv gives every agent the same current design context through a machine-readable contract and a read-only MCP interface. It helps agents reuse what exists, follow established decisions, and surface inconsistencies before they ship.
Primitiv runs locally. Your code never leaves your machine.
## Quick start
Run these commands from your project root:
```bash
npx @ai-by-design/primitiv init
npx @ai-by-design/primitiv build
npx @ai-by-design/primitiv serve
```
`init` sets up Primitiv for the current project, `build` creates its design contract, and `serve` makes that contract available to MCP-compatible agents.
See the [Primitiv documentation](https://primitiv.design/docs) for installation, configuration, commands, and integration guides.
> [!IMPORTANT]
> Keep Primitiv configured at project level. A global MCP configuration can serve the wrong project's contract when you switch repositories.
## Capabilities
- Bring design context from your codebase, Figma, and Storybook together
- Make existing tokens, components, rules, and rationale available to agents
- Surface conflicts, drift, and hardcoded token misuse
- Provide read-only access from MCP-compatible agents and editors
- Verify that the contract stays current in CI
Primitiv also checks local JSX usage against each codebase component's complete finite prop domains. Known out-of-domain values produce a pending `within-source` conflict, even under `auto-resolve`. Align the JSX usage or widen the declared domain to resolve it. `warn` reports these conflicts without blocking; `error` and `verify --strict` exit with code 2. Dynamic values and incomplete domains remain unknown.
When component evidence cannot be compared, `primitiv verify` reports a short diagnostic summary. Use `primitiv verify --verbose` for the reasons, or `--json` for a structured report. Diagnostics explain uncertainty and do not count as conflicts or directly fail verification; changes to them can still make the saved contract stale. `--fast` reports saved diagnostics instead of rebuilding them.
Agents can read diagnostic counts in the MCP summary and paginated details through `get_design_context` with `category: "diagnostics"`.
## Component drift in CI
Run `primitiv verify` against your saved contract to check declared prop facts, finite variant values, observed JSX values, and component relationships. Verification also compares Storybook default args, story args, and control choices, including mapped values. Story labels and other presentation metadata do not count as API drift. Observations and examples describe static source evidence, not runtime frequency or breaking-change severity.
For example, changing a `Button` usage from `size="sm"` to `size="lg"` is detected even when the number of JSX sites stays the same. Drift messages identify the component ID and field path, such as `components/Button` and `usage.props.size`.
Normal verification scans current sources in memory and uses their current conflicts for reporting and governance. Introducing or fixing an out-of-domain JSX value takes effect in verification immediately. The saved contract remains the drift baseline and is never rewritten by verification: run `primitiv build` to refresh it, then verify again. MCP continues serving the saved contract until it is rebuilt and reloaded.
Failed sources and incomplete or truncated evidence cannot prove that an unavailable fact was removed or that a conflict was resolved. Verification reports available changes and comparison uncertainty. Older contracts remain readable; newly available evidence makes them stale until rebuilt.
Stale evidence exits with code 1, or 2 under `--strict`. Pending conflicts exit with code 2 under `error` governance or `--strict`; warn-only conflicts do not independently fail verification. `--fast` uses saved findings and file modification times instead of scanning current API evidence, so use normal verification in CI. Use `--json` for the verification result and `--verbose` for comparison diagnostic details.
## Project links
- [Documentation](https://primitiv.design/docs)
- [Changelog](./CHANGELOG.md)
- [Contributing](./CONTRIBUTING.md)
- [Code of Conduct](./CODE_OF_CONDUCT.md)
- [Security](./SECURITY.md)
- [Issues](https://github.com/AI-by-design/primitiv/issues)
- [Apache-2.0 license](./LICENSE)
TDQS
Scored across 9 tools
Most tools have distinct purposes, but there are real overlaps: get_component vs get_component_context (both inspect a single component), and get_design_context vs get_component_catalog (both give a system overview). The descriptions mitigate this heavily with explicit cross-references ('for X, use Y instead'), keeping misselection risk low but nonzero.
Eight of nine tools use a clean get_<noun> pattern (get_component, get_token, get_conflicts, get_violations, get_inferred_rules, get_design_context, get_component_catalog, get_component_context). find_components is the lone deviation, but the search-vs-fetch distinction is meaningful and readable.
Nine tools is well-scoped for a read-only design-system inspection server. Each tool covers a distinct facet (catalog, discovery, component detail, tokens, rules, conflicts, violations, context) without redundancy in count.
The surface covers discovery, component lookup, token lookup, inferred rules, conflicts, and violations, giving broad lifecycle coverage for a read-only inspection role. Minor gaps exist (no explicit snapshot-compare or diagnostics tool outside get_design_context), but agents can work around these.