BQ

bearisbug/quilt

Developer tools
105 stars 2 forks Quality 68 Trend 35Apache-2.0

AI-native infinite-canvas design tool: describe an app, get multi-screen HTML designs on an infinite canvas, click through them as a prototype, and let your local coding agent read and write the...

Overview

AI-native infinite-canvas design tool. Describe an app, get consistent multi-screen HTML designs on an infinite canvas, click through them as a prototype, and let your coding agent read and write the canvas over MCP. Quilt runs on your machine: one process, no account, no cloud backend, data in ~/.quilt. Generation goes through the channel you pick: your Claude subscription (the claude CLI), an Anthropic, Gemini or OpenAI-compatible API key, or a Claude Code session you already have open. - Describe the app. Quilt plans a 4–6 screen main flow (or the 1–4 screens you ask for), generates each screen as self-contained HTML in the project's design system, lints and screenshots it, and lays it out on the canvas. Ask for up to 4 candidates per screen and adopt one. - Select screens and describe the change. In a focused screen, ⌘E picks any element: change its text, classes or link with zero tokens, or have AI regenerate just that block.

README

Quilt

AI-native infinite-canvas design tool. Describe an app, get consistent multi-screen HTML designs on an infinite canvas, click through them as a prototype, and let your coding agent read and write the canvas over MCP.

English · 中文


Quilt runs on your machine: one process, no account, no cloud backend, data in ~/.quilt. Generation goes through the channel you pick: your Claude subscription (the claude CLI), an Anthropic, Gemini or OpenAI-compatible API key, or a Claude Code session you already have open.

What it does

  • Generate. Describe the app. Quilt plans a 4–6 screen main flow (or the 1–4 screens you ask for), generates each screen as self-contained HTML in the project’s design system, lints and screenshots it, and lays it out on the canvas. Ask for up to 4 candidates per screen and adopt one.
  • Edit. Select screens and describe the change. In a focused screen, ⌘E picks any element: change its text, classes or link with zero tokens, or have AI regenerate just that block.
  • Sketchbook. A full-page board for one-off components and pages outside any project. Describe one, refine it by picking elements, step through versions, then put it into a project as a new screen, over a screen, or in place of one block.
  • Canvas. Pan, zoom, drag, align and distribute. ⌘K jumps to any screen; a minimap and a filterable screen list keep large projects navigable. Double-click a screen to use it live.
  • Prototype. Links, forms and data-href buttons move between screens with state kept and a back stack. Overlay screens (sheets, dialogs) open on top of the current one; state variants (empty, error, signed out) share a route. Broken links are flagged and fixed in one click. Export the whole prototype as one offline HTML file.
  • Design system. A seed colour or an explicit brand palette (light and dark) yields tokens, a DESIGN.md and component recipes. Upload assets, save presets, and re-flow every screen when tokens change.
  • Shared components. Tab bars, app bars and sidebars live on the canvas as components; edit one and every screen using it updates without a model call.
  • History. Every generation, edit and agent write is a revision you can roll back to.
  • Together. People on your network who open the same project see each other’s cursors, selections and views, and can follow one another.
  • Settings. Generation channels (keys encrypted at rest), a usage dashboard by day, model, project and task, an optional local record of UI actions and model calls, and a Chinese or English interface.
  • MCP, both ways. Your coding agent gets 57 tools and 7 resources at http://127.0.0.1:3100/mcp. Quilt can also hand a job to a running Claude Code session.

How it works

Browser (React 19 canvas) ──REST / SSE──▶ quilt process (Hono, 127.0.0.1:3100)
                          ◀─iframe──────  preview origin (127.0.0.1:3101, read-only HTML)
                                          ├─ in-process job queue + worker (LLM, lint, inject, screenshot)
                                          ├─ MCP server (Streamable HTTP, same service layer as REST)
                                          ├─ chat jobs over the API (Claude Agent SDK subprocess, talks to the same MCP)
                                          └─ agent delivery (hands jobs to a local Claude Code session)
                                          ~/.quilt: PGlite database · objects/ · config.env

Screens are plain HTML with Tailwind classes and the project’s tokens; stable element ids let an edit target one block. The preview runs on a separate origin, so generated scripts cannot reach Quilt’s own storage.

docs/DESIGN.md is the single source of truth: requirements, data model, API contract, state machines and ADRs. docs/TEST.md holds the test cases and the log of every test round.

Quick start

Requirements:

  • Node.js 22 or newer, pnpm 11
  • Chrome or Edge for screenshots (otherwise run npx playwright install chromium once)
  • A generation channel: the claude CLI logged in (the default, LLM_DRIVER=agent-sdk), an Anthropic or Gemini API key, or an OpenAI-compatible endpoint added in settings

Run the packaged app

pnpm install
pnpm build                       # builds the web bundle and apps/cli/dist
node apps/cli/bin/quilt.js       # or: npx quilt-canvas, once the package is published

The first run creates ~/.quilt (embedded PGlite database, object store, config.env with generated secrets), runs migrations and opens http://127.0.0.1:3100. Run it again with the same home and your projects are there.

Flags: --home , --port / --preview-port (default 3100 / 3101), --no-open. The default channel is set in ~/.quilt/config.env:

LLM_DRIVER=agent-sdk      # agent-sdk (local Claude subscription) | anthropic | gemini
ANTHROPIC_API_KEY=
GEMINI_API_KEY=

Run from source

pnpm install
cp .env.example .env             # leave DATABASE_URL empty to use embedded PGlite
docker compose up -d             # optional: Postgres on 127.0.0.1:5439 if you set DATABASE_URL
pnpm dev                         # API + worker + preview on 3100/3101, Vite on 6688

Open http://localhost:6688. Migrations run at API startup; every key in .env.example is documented inline.

Connect your coding agent

claude mcp add --transport http quilt http://127.0.0.1:3100/mcp

The server listens on loopback only, so there is no authentication. Everything the canvas and the sketchbook do is available as a tool; only API keys stay in the settings panel.

Read with get_outline (a compact summary of every screen) before get_screen. Keep writes small: patch_screen for a partial change, create_upload_url plus several append_upload chunks for a screen over ~8 KB, because one very long tool argument can cut a streamed model response short. Writes carry expectedRevisionId and return 409 on a stale base, so two writers cannot overwrite each other.

The other direction: choose “hand to local Claude Code” as the channel in the composer and pick a running session. Quilt delivers the prompt there; the session writes back over the same MCP and closes the job.

Repository layout

apps/api        Hono server: REST, MCP, SSE, preview origin, in-process worker, Drizzle schema + migrations
apps/web        Vite + React 19 + Tailwind 4 canvas and sketchbook
apps/cli        esbuild bundle of api + core + web → the `quilt-canvas` npm package
packages/core   shared: zod schemas, prompt contract, lint rules, runtime injection, export, tokens, outline
tests/unit      node:test unit tests for the pure functions in core and the canvas (pnpm test)
tests/e2e       Playwright scripts that execute the cases in docs/TEST.md
docs/CHANGELOG.md older change-log rows moved out of DESIGN.md / TEST.md
docs/DESIGN.md  design document (requirements, data model, API contract, state machines, ADRs)
docs/TEST.md    test cases with REQ traceability and the execution log
CLAUDE.md       working discipline for coding agents contributing to this repo

Development

pnpm typecheck                   # tsc across core / api / web
pnpm test                        # unit tests (node:test, ~1.5 s, no database or browser)
pnpm build                       # web bundle + CLI package
pnpm seed                        # wipe the database DATABASE_URL points at, create two demo projects
pnpm mcp:call  ''    # call an MCP tool against the running server

The end-to-end suites in tests/e2e run against an isolated stack (scripts/e2e-stack.sh; scripts/e2e-all.sh runs them in order). They wipe the database they point at, so they refuse to start unless its name ends in _test. LIVE_LLM=0 skips the turns that need a real model; environment details are in docs/TEST.md §3.

Every change goes the same way: update docs/DESIGN.md, then the code, then the affected cases in docs/TEST.md, then run and log a round.

Status

v1.42, local edition: it runs on one machine, and people on the same network can open it together. Mobile and desktop screens, plus free-form drafts in the sketchbook. Deferred, not dropped: multi-user SaaS (login, quotas, remote dispatch). Out of scope: production React code generation, native rendering.

License

Apache-2.0. See LICENSE.

View the full README on GitHub

Install

This server does not publish a one-line install command.

Open the repository installation guide New to MCP? Start with the mcpskill.org guide →