systemix docs

For engineers

How Systemix works for engineers — MDX contracts in your repo, code-first tokens, drift reports, three doors into the same loop.

What Systemix does for you

The design system becomes files you own: each component and token is an MDX contract with rationale, states, and drift status in the frontmatter (see a real one: contract/tokens/color-primary). Tokens are canonical in CSS (globals.css), not in a design tool — Figma is an optional adapter, never the source of truth. Documentation can't rot because the loop writes decisions back into the same files your PRs touch.

The loop gives your shipping a memory: experiments are MDX files with a hypothesis, live evidence, and the decision they earned. A drift report scores how far the shipped product diverged from the contract, and the history is kept so you see the trend, not just today's snapshot.

Your 10-minute start

  1. Init.

    npx @getsystemix/cli init

    Scaffolds experiments/ (+ LEARNINGS.md), design/ (DESIGN.md · guardrails.mdx · tokens.css), systemix.config.yaml, a per-instance CLAUDE.md, the loop skills in .claude/skills/, and registers the systemix-mcp server. Commit all of it — the instance is reproducible.

  2. Author the first experiment. In Claude Code: /init-experiment <id> — or scriptable: systemix experiment new.

  3. Wire the signal. /connect-signal walks the PostHog key + /ingest reverse proxy. Without it, experiments still author and close — just without live evidence.

  4. Run the loop.

    systemix loop        # sweep all running experiments

    Evidence → evaluate vs thresholds → close-proposal card. A human closes.

Your weekly loop

  • systemix loop on a daily cron advances experiments to decision-ready.
  • Run /drift-report (or press play on it in the Home dashboard) — every audit lands in the memory feed with score and offenders.
  • Pick your door per task: CLI in CI, skills in Claude Code, MCP from any agent. Same files underneath.

Where next

On this page