Open-Source Design Tooling:
Gaps & Ideas

What it does

A CLI that reads any W3C-compliant .tokens.json file (or Tokens Studio export) and cross-checks all color tokens for WCAG AA/AAA compliance across every realistic foreground × background combination. Outputs a structured report: which token pairs fail, which modes (light/dark/high-contrast) break, which components are likely affected. No browser. No DOM. Pure token-level audit.

Why it doesn't exist

• Stark checks accessibility inside Figma but is paid and not scriptable
• axe-core and Pa11y operate on a rendered DOM — you can't run them in CI without a browser and a full build
• No tool consumes the W3C token format (just stabilized Oct 2025) and emits a11y reports in a pipeline-safe way

Build scope

• Parse W3C token JSON or Style Dictionary output
• Build foreground/background permutations from semantic token relationships
• Apply WCAG 2.1 / APCA contrast algorithms
• Output SARIF or JSON for CI integration

What it does

A CLI + optional MCP server that compares a Figma component's declared styles (via Figma REST API or the existing MCP get_design_context) to what's actually in your codebase — CSS variables, Tailwind classes, component props. Outputs a semantic diff: "Button background in Figma is --color-brand-500, but your code uses #2563EB hardcoded" or "Figma says border-radius is 8px; code says 6px."

Why it doesn't exist

• Figma MCP exposes design context but no tool systematically runs it against the codebase
• Visual regression tools catch screenshot differences, not semantic token drift
• The gap between "designer updates Figma" and "developer updates code" is invisible until someone notices visually
• Building this per team is reported as a significant engineering effort — everyone's doing it in isolation

Build scope

• Figma API / MCP wrapper to extract token refs from a node
• CSS / Tailwind / CSS-in-JS parser for computed values per component
• Diff engine with configurable tolerance (pixel vs. semantic token name)
• GitHub Action wrapper for CI

What it does

A CLI that polls Figma's version history API and generates a structured, human-readable CHANGELOG for your design system. Detects: token renames, token value changes, component deletion, variant additions/removals, library style changes. Outputs Markdown changelogs, JSON diffs, or posts to Slack/GitHub Discussions. Essentially git log for your Figma file.

Why it doesn't exist

• Figma has version history in the UI but no structured diff API between versions
• Designers have no equivalent of git log or CHANGELOG.md — changes are communicated manually via Slack or Notion pages
• Design system consumers (engineers) often find out about breaking changes by noticing visual bugs in production
• No open-source project traverses Figma's node tree across versions to detect semantic changes

Build scope

• Figma REST API version history traversal
• Node-tree diffing (components, styles, variables)
• Change categorization: breaking vs. additive vs. cosmetic
• Output adapters: Markdown, JSON, Slack webhook

What it does

A CLI for design systems that support multiple brands sharing a base token set. Validates the inheritance tree: catches circular references, ensures every brand has all required overrides, detects tokens that fall back to base values unintentionally, and flags orphaned tokens. Think eslint for your token architecture.

Why it doesn't exist

• Style Dictionary can transform tokens but doesn't validate inheritance correctness
• The W3C spec defines the format but not validation rules for multi-brand systems
• Teams building white-label or multi-brand design systems hit these issues at scale with no tooling to guard against them
• Authoring vs. consuming token gaps are a known open problem in the W3C community group

Build scope

• Token graph builder from W3C format files
• Cycle detection and required-override schema definitions
• Reporter with rule-level configuration (like ESLint rules)
• GitHub Action or pre-commit hook integration

What it does

A CLI that extracts all font sizes, weights, and line heights from a Figma file or a CSS codebase, then compares them against the declared type token scale — flagging rogue values that don't fit the system, violations of vertical rhythm consistency, and WCAG readability standards. Answers the question: "Does the code actually match the type scale we defined?"

Why it doesn't exist

• Typography auditing lives inside Figma plugins (paid) or browser DevTools (manual)
• No CLI tool extracts type values from both Figma and code and cross-references them
• Large codebases accumulate rogue font sizes over time with no automated enforcement beyond a linter rule that covers only new code
• Vertical rhythm and modular scale validation aren't covered by any existing open-source tool

Build scope

• Figma API extractor for text style nodes
• CSS / Tailwind parser for font-size, font-weight, line-height usage
• Scale validator: detect values off the declared type ramp
• WCAG minimum text size and contrast check