Agents build screens. A design system keeps them consistent.
Local-first UX design tool for AI agents: agents design through MCP, you review in the browser, and the state is plain files on your disk.
npm install artisign
Screens drift. Every fix costs more than the last.
Agents write UI one screen at a time. Without a shared system, each screen re-derives its own greys, its own spacing, its own fourth button style — and consistency then depends on every future edit remembering every past decision, which no agent and no human does reliably.
A screen full of raw hex and pixel values is unfinished work: it cannot be re-themed, it drifts from its sibling screens, and every future edit costs more.
Re-deriving visual decisions per screen is also the expensive way to do it. An agent that reads a design-system summary and composes refs needs far fewer tokens than one that re-derives visual decisions per screen.
Three moving parts, no server you have to trust.
One Node process on 127.0.0.1. No database, no accounts, no hosting.
The agent designs through MCP
Claude Code or Claude Desktop connects to Artisign as an MCP server and gets tools for tiered reads, surgical writes, design-system mutation, flows, comments, and screenshots. The agent reads the design system before it designs anything, then composes screens from refs.
The state is plain files on your disk
Tokens, components, screens, flows and comments are files in your project folder — augmented HTML, JSON and JSONL. Everything is human-readable and diffable. With autoCommit on, every write becomes one git commit named after the tool and its target — that is the audit log.
You watch it happen in the browser, and comment
The preview at 127.0.0.1:4711 renders the same source the agent writes. Any file change shows up within about 200 ms over SSE. Click an element to anchor a comment; the agent picks it up with list_comments and answers with reply_comment. Click an element with a flow target to jump to the screen it points at.
Four surfaces you work in.
Everything below is the running app, not a mock-up of it. The preview renders the same files the agent writes, so what you review is what ships.
Board
The Board tab lays every screen in the project out as a tile on one surface and draws the click routes between them, so a flow is something you see rather than something you reconstruct.
Flow mode
Flow mode makes the design clickable: click an element that carries a flow target and the preview jumps to the screen it points at — so a screen nobody can reach, or a button that goes nowhere, is something you find by clicking instead of by reading a spec.
Screen details
Two panels flank the screen: Elements lists its nodes by the ids the agent addresses them with, and Notes carries what a screenshot cannot — the states, the edge cases, the content rules, and the spec behind a tag — rendered as Markdown.
Mockups
When the question is which direction rather than which detail, the agent writes one mockup variant per option — raw HTML, outside the design system on purpose — and the preview renders them side by side; the one that wins is promoted into a real screen that plays by the design system's rules from then on.
Four things it does that a folder of HTML does not.
Consistency across screens
The design system is first-class: screens store refs, never inline values. When every button is $btn-primary and every gap is $spacing.md, screens cannot drift apart. Rebranding is one set_tokens call — change the token and every screen, component and pattern that references it follows.
<button id="btn-login" class="$btn-primary" data-variant="hover"
style="padding-inline: $spacing.md" data-flow-target="dashboard">
Log in
</button>
$name in class is a component ref, $name in a style value is a token ref.
Token efficiency
Built for small contexts: tiered reads, field selection, and diff mode on writes. find_nodes answers cross-screen questions in one call instead of reading every screen, and inspect_node returns computed geometry as text where a screenshot would cost vision tokens.
Flows as data
Click routes are data, not documentation. A flow target is an attribute on the element that triggers it, edited later with set_flow without touching a screen file — and a CTA that goes nowhere is a design you can detect instead of a paragraph nobody read.
Render determinism
The preview renders the source, so preview equals output by construction. Screens, design-system variants and screenshots all go through the same baseline document: box-sizing: border-box everywhere, zero body margin, antialiased text. A screen root declared width: 390px with padding measures exactly 390 px.
The tool designed its own interface.
Artisign's browser preview is designed in Artisign. design/ in the repo is a real project in the on-disk format above — tokens, components, screens, flows — and it is the source the interface at 127.0.0.1:4711 was designed from.
It is not a demo project. Every token that has a counterpart in the shipped stylesheet — all 19 colours, the six spacing steps, radius.pill and shadow.menu — mirrors it by value and by role name, so the two cannot quietly drift apart: change one and the mismatch is visible in the other.
That makes it the largest worked example in the repo, and the honest answer to whether the tool is good enough to build with — it built this one.
Three commands.
Node.js ≥ 20.19, on macOS or Linux.
1 — Install into a directory of your own
mkdir artisign && cd artisign
npm install artisignnpx artisign works too and needs no setup. Screenshots work on both paths — Playwright installed next to a local install, or pointed at with ARTISIGN_PLAYWRIGHT_DIR when running through npx.
2 — Start the daemon
./node_modules/.bin/artisign start ./my-projectThe daemon runs on 127.0.0.1:4711 and can hold several projects open at once. Then open http://127.0.0.1:4711.
3 — Connect Claude Code
claude mcp add --transport http artisign "http://127.0.0.1:4711/mcp?project=/absolute/path/to/my-project"The ?project= parameter scopes every tool call to that project, so several coding projects can share one daemon without ever restarting it. Claude Desktop connects over stdio instead — the README has that config.
Optional — screenshots
npm install --no-save playwright && npx playwright install chromiumget_screenshot and inspect_node need a real browser, which is intentionally not bundled. Run this in the same directory you installed artisign into, or install Playwright anywhere and point Artisign at it with ARTISIGN_PLAYWRIGHT_DIR — set for the process that starts the daemon. Every other tool works without it.
Everything else — the tool reference, the agent guide, the design workflow tutorial — is in the repo.
What it does not do.
Every limit below is already in the README.
- macOS and Linux only. Windows is not supported: the store's atomic writes and its path handling have never been verified there, so package.json declares the platform via os and npm install refuses rather than failing somewhere later.
- Node.js ≥ 20.19.
- Screenshots are optional and not bundled. get_screenshot and inspect_node need Playwright, an optional peer dependency — npm installs neither it nor its ~150 MB of browser binaries unless you ask. Without it, those two tools fail with the install command in the error message; every other tool works.
- No telemetry, no account, no update check. Artisign collects nothing. Two things reach the network, neither of them about you: import_html fetches whatever URL you hand it, and the first render fetches the font families named in your tokens — plus the Material Symbols Rounded icon font — from Google Fonts, then caches them locally.
- AGPL-3.0. Your designs are yours: the licence covers Artisign's own source code, not the screens, components, tokens or projects you create with it. The name is not licensed — forks may use the code but need their own name.
- Code contributions are not accepted right now. Bug reports, feature ideas and questions are; CONTRIBUTING.md explains why. Vulnerabilities go through private reporting, never a public issue.