open-design: Open Design: The CLI Becomes the Design Engine

A local-first orchestration layer that turns installed coding agents, Markdown design systems, and a daemon-sidecar architecture into a vendor-neutral design-to-code stack.

9 min read • View on GitHub • More from nexu-io

A wide desk scene shows several terminal windows wired into a central daemon box, with a design canvas and preview pane on the same workstation. The image explains that Open Design treats installed CLI tools as infrastructure, not just commands. — Open Design does not begin with a model API. It begins with the tools already on your machine and routes them through a local control plane.

Key Takeaways

Open Design treats installed CLI agents as first-class infrastructure, so the local machine becomes the runtime instead of a cloud model endpoint.
The daemon is the control plane that coordinates chat, file work, previews, and media jobs without turning the browser into the brain.
Markdown is not documentation here, it is an operating layer for skills and design systems that shapes behavior without extra schemas.
The project’s deepest trick is a recursive local loop, where the CLI can call back into the daemon to generate media and return artifacts.

The surprising idea: the model is not the product

Open Design is easy to mistake for another AI design toy. It is closer to a local orchestration layer that happens to generate interfaces, slides, images, and media. The key move is not a new foundation model. It is the decision to drive whatever coding agent CLI is already installed on the machine.

That shifts the center of gravity. Auth, permissions, file access, and tool calling come from the local environment instead of a proprietary wrapper. The result feels less like SaaS and more like Unix: small commands, explicit routing, and a system that assumes the user owns the runtime.

There is no checkout, no self-host, no Vercel deploy, no swap-in-your-own-agent.

Project README, Repository documentation · nexu-io/open-design README

Why the daemon matters

The daemon is the control plane. It coordinates chats, sandboxed previews, file operations, sidecars, and the media pipeline, so the browser is just one surface on top of a local service. That matters because the project does not rely on one-off shell tricks. It needs state, routing, and a place to centralize the conversation between the user, the agent, and the filesystem.

The daemon sits in the middle of the loop. It receives requests, routes work, and hands results back to the preview layer without giving up local control.

This is also where sidecars make sense. Long-running jobs can leave the main UI responsive while the daemon keeps track of projects, artifacts, and callback paths. In other words, the repo is not just spawning processes. It is managing a small local system.

CLI hijacking, but make it deliberate

The most distinctive engineering pattern sits in agents.ts. The daemon scans $PATH, probes known CLIs with --help, and adapts to the features each agent exposes. If a CLI supports partial streaming or a particular flag, the daemon learns that surface instead of forcing a single vendor contract.

That choice is pragmatic and slightly rebellious. It inherits the user’s existing tools rather than asking them to re-platform around a new SDK. It also makes Open Design resilient when agent surfaces change, because the project is reading capabilities rather than hard-coding assumptions.

Axis	Open Design	Cloud-first design tools
Detection	Scans installed CLIs and probes capabilities	Calls a fixed vendor API
Control layer	Local daemon and sidecars	Remote service and web app
Data locality	Stays on the machine by default	Lives in the provider’s cloud
Extensibility	Markdown registries and CLI adapters	Plugins or closed integrations
Failure mode	Missing CLI or permission mismatch	Rate limits, account lock-in, service policy
Runtime ownership	User-owned environment	Vendor-owned environment

A close technical scene shows a terminal running od media generate, sending an arrow back into a daemon box, then out through a media pipeline and back into a preview pane. The image explains the recursive loop where a local command becomes a bridge back to the orchestrator. — The clever part is not that Open Design can generate media. It is that the agent can summon that work by calling back into the local daemon.

Markdown becomes configuration

Open Design treats Markdown as a control surface. Skills and design systems are stored as readable files and parsed with front matter, so behavior and visual constraints can be shaped without writing a new schema or editing TypeScript. That lowers the barrier for contributions and makes the system legible to non-engineers.

This is a subtle but important product decision. A Markdown registry is less intimidating than a database table or a JSON schema, but it still gives the daemon enough structure to drive workflows. The project also uses heuristics to extract design swatches and surface aesthetic cues, which means prose can become operational input.

// Conceptual flow from the daemon
const skills = await listSkills(projectRoot)
const designSystems = await listDesignSystems(projectRoot)
const prompt = composeSystemPrompt({
  identity: officialIdentity,
  philosophy: huashu,
  designSystem: designSystems.current,
  skill: skills.current,
  craft: reusableCraftSections,
})

That composition model matters because it stacks constraints instead of replacing them. The agent gets identity, philosophy, brand rules, skill instructions, and craft guidance in one assembled prompt. The result is a local pipeline where Markdown is not passive content. It is part of the runtime.

How the media loop-back changes the feel of the tool

The bimodal od CLI is the project’s most delightful mechanic. In one mode it starts the daemon. In another, od media generate acts as a callback path, so an agent can ask the local runtime to do heavy media work without breaking the orchestration model.

That makes the system feel recursive in a good way. The agent is not trying to do everything itself. It calls a local command, the command talks back to the daemon, and the daemon routes the job to the media pipeline before returning the artifact. The control surface stays simple while the work behind it gets complex.

How it stacks up against cloud-first design tools

Tool	Deployment	Primary control layer	Model dependency	Extensibility	Data locality	Output breadth
Open Design	Local-first	Daemon plus CLI adapters	Multiple local or installed CLIs	Markdown skills and design systems	On the machine by default	Web, desktop, mobile, slides, images, videos
Anthropic Claude Design	Cloud	Vendor app	Anthropic stack	Closed ecosystem	Provider cloud	Design and code workflows
Figma with AI	Cloud	Design app and plugins	Mixed plugin ecosystem	Plugin based	Provider cloud	Interface design and collaboration
Penpot	Web or self-hosted	Design app	Growing AI support	Open source project extensions	User managed or hosted	Design and prototyping
Generic local AI tools	Local or hybrid	Chat interface	Varies by model	Broad but unspecialized	Usually local	General assistance, not design native

The comparison is not about feature counting. It is about where control lives. Open Design is unusual because it puts the runtime on the user’s machine, lets the agent discover capabilities instead of assuming them, and keeps extensibility close to plain text rather than closed integrations.

What this architecture suggests about the future

Open Design points to a broader shift from model-centered products to orchestration-centered products. The interesting unit is no longer the model prompt or the single UI. It is the glue between local tools, local state, and a system that can route work without surrendering control.

That is why the repo stands out. It does not just clone a cloud feature set. It reassigns trust. The browser becomes a window, the CLI becomes infrastructure, and the daemon becomes the place where design intent turns into artifacts.