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
-
Init.
npx @getsystemix/cli initScaffolds
experiments/(+LEARNINGS.md),design/(DESIGN.md · guardrails.mdx · tokens.css),systemix.config.yaml, a per-instanceCLAUDE.md, the loop skills in.claude/skills/, and registers thesystemix-mcpserver. Commit all of it — the instance is reproducible. -
Author the first experiment. In Claude Code:
/init-experiment <id>— or scriptable:systemix experiment new. -
Wire the signal.
/connect-signalwalks the PostHog key +/ingestreverse proxy. Without it, experiments still author and close — just without live evidence. -
Run the loop.
systemix loop # sweep all running experimentsEvidence → evaluate vs thresholds → close-proposal card. A human closes.
Your weekly loop
systemix loopon 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
- The contract file structure
- Why files & loops
- Your landing page: /for/engineers