Why we built Open Design as a skill layer, not a product

The strongest coding agent on your laptop right now is Claude, Codex, Cursor, Gemini, OpenCode, or Qwen. We don’t think you need another one. What’s missing is not raw intelligence — it’s taste, structure, and a workflow that respects design as a craft.

Open Design is our attempt at that missing layer. It’s not a chat product. It’s not a design tool that “uses AI under the hood.” It’s a thin skill layer — a folder of SKILL.md files, a portable library of design systems, and a daemon that auto-detects your existing CLI agents and wires them together.

This post explains why we made that choice, what it implies for how you’ll use Open Design, and why “layer, not product” is a bet on longevity rather than a shortcut.

A product would be the wrong shape

The instinct, when starting an AI design project in 2026, is to build a new app: a chat interface, a canvas, a billing system, a model bill that grows linearly with your user count. We considered that path and rejected it for three reasons.

The chat interface is a commodity

Every user already has a capable agent and a chat box they trust. Adding a worse one — wrapped in our brand, missing the muscle memory they’ve built — helps nobody. The interface is not where the value is. The value is in what the agent does after you hit enter: whether it produces a deck that looks designed or a wall of divs.

The model bill is a tax on creativity

Bundle inference into the product and the economics force your hand. You have to mark the tokens up, throttle long sessions, and ration access to the newest models so your margin survives. Every one of those moves punishes the exact behavior a design tool should reward: iterating, exploring, and running the agent again because the third draft is where the work gets good.

Lock-in is the wrong default

Designers should be able to leave with their files, their systems, and their skills intact. A product wraps everything in proprietary state — export it and you get a flattened shadow of the real thing. A skill layer has nothing to wrap, because the artifacts are the files. Leaving costs nothing, which is exactly why staying means something.

So we built the layer instead. Drop a folder, restart the daemon, the skill appears. Take the folder with you, drop it into a different agent, the skill works there too.

What a skill actually is

A skill in Open Design is a SKILL.md file plus optional supporting assets in the same folder. The Markdown file describes:

What the skill does — one paragraph, in plain English
When to invoke it — the trigger conditions, written so the agent can route correctly
The shape of the output — HTML, PDF, slides, a Markdown brief
The constraints — palette in OKLch, font stack, layout posture, brand vocabulary

The agent reads the file, decides whether to invoke, and writes the output to disk. There is no plugin system, no API surface, no version compatibility matrix. If you can write Markdown, you can ship a skill.

Anatomy of a skill

Concretely, a skill is a directory the daemon discovers at boot:

skills/
  magazine-poster/
    SKILL.md          # the contract: trigger, output shape, constraints
    examples/
      launch.html     # a known-good artifact the agent can pattern-match

The SKILL.md front matter names the skill and its triggers; the body is guidance the agent reads like a brief. Nothing registers the skill but its presence on disk — no manifest to bump, no build step, no review queue.

Why files beat plugins

This is intentional. We’ve watched plugin ecosystems decay for fifteen years — each one a trade between expressiveness and longevity, won by neither. A plugin is a snapshot of someone’s API in a particular year; the runtime moves, the API breaks, and the workflow you depended on is gone. Files don’t break. A SKILL.md written today reads exactly the same to an agent two years from now, and to a human with no tools at all.

A single markdown document sheet with plain text lines, selected in a green frame on a near-white editorial ground — A skill is just a file — plain Markdown an agent reads, not a feature locked inside a product.

Why systems are also Markdown

Open Design ships dozens of design systems — Linear, Vercel, Stripe, Apple, Cursor, Figma, and more — as DESIGN.md files. Same idea: portable, readable, agent-ingestible.

A design system, in this context, is not a Figma library. It’s a contract:

## Color
--bg: oklch(98% 0.01 95);
--ink: oklch(20% 0.02 260);
--accent: oklch(72% 0.19 35);

## Type
Display — Albert Sans, 600, -0.02em
Body — Albert Sans, 400, 1.7 line-height

## Posture
Generous whitespace. One accent, used sparingly. No drop shadows.

The agent reads the contract and produces work that respects it — colors in OKLch so they stay perceptually even, a type ramp it won’t drift from, a layout posture that keeps ten generated screens feeling like one product.

Mix, fork, and own

Because a system is just text, you can fork one and edit it in place, ship a variant, or write your own from scratch in thirty minutes. You can even mix systems mid-project — pull the typography from Linear, the color logic from Vercel, the layout from a custom in-house spec — because there’s no binary format standing between you and the rules. The full mechanics of how skills and systems compose are covered in 31 skills, 72 systems: how the Open Design library works.

BYOK is the only honest model

Open Design runs on bring-your-own-key. You paste a base URL and an API key for any OpenAI-compatible endpoint — DeepSeek, Groq, OpenRouter, your own self-hosted vLLM — and you’re done:

OPENAI_BASE_URL=https://api.deepseek.com/v1
OPENAI_API_KEY=sk-…

We don’t run inference. We don’t take a margin on tokens. We don’t have a billing relationship with you. That’s not a sustainability problem — it’s the only honest answer to the question “who pays when the agent runs?”

Privacy follows from the same choice

Because the daemon calls the provider directly from your machine, your prompts never transit our servers. There is no proxy to log them, no analytics pipeline quietly retaining your unreleased work. For agency work or anything under NDA, “where does this run?” stops being a procurement conversation and becomes a setting. The deeper trade-offs — and the rough edges that still exist — are in the BYOK reality check.

The answer to who pays is: you do, directly, to the model provider you chose. We get out of the way.

What this means for you

If you want a polished SaaS with a nice chat box and a single subscription, we’re not the right tool. There are good products in that shape — use them.

If you want a workflow where:

the agent you already trust does the work,
the skills are files you can read and edit,
the design systems are portable across projects and agents,
and the bill goes to the model provider, not us —

then Open Design is built for you. Drop into the GitHub repo, run pnpm tools-dev, point your agent at a skill, and ship.

The skill layer wins because it doesn’t compete with the agent on your laptop. It augments it.

31 skills, 72 systems: how the Open Design library works — the four primitives this layer is built from
BYOK design workflow: run Claude, Codex, or Qwen on your own key — the bring-your-own-key model in practice
The open-source alternative to Figma — where the “layer, not product” bet lands against the incumbent