Noureddine RAMDI / Open Design: repurposing coding-agent CLIs into a modular local-first design engine

Created Sat, 02 May 2026 20:48:38 +0000 Modified Sat, 23 May 2026 20:41:27 +0000
959 Words
github-stars typescript ai-agents local-first design-systems cli composable-architecture

nexu-io/open-design

Open Design flips the usual AI design tool model on its head by not shipping its own agent. Instead, it hooks into whatever coding-agent CLIs you already have installed on your machine, wiring them into a local daemon that orchestrates a skill-driven design workflow. This means you get a deterministic, composable design engine that runs locally, with deterministic visual directions, sandboxed previews, and export options, all while respecting your choice of AI providers and keys.

How open design repurposes coding-agent CLIs into a modular design engine

At its core, Open Design is a local-first, open-source alternative to Anthropic’s Claude Design. It doesn’t bundle its own AI model or agent but auto-detects 12 coding-agent CLIs on your PATH. It then runs these agents as subprocesses via a local daemon, injecting Read/Write/Bash/WebFetch capabilities as sandboxed interfaces into real project folders.

The architecture leans on 31 composable skills that build up design workflows, supported by 72+ brand-grade design systems and a gallery of 93 ready-to-replicate prompts. The system supports BYOK (Bring Your Own Key) at every layer, meaning you control the credentials for the AI backends, including an OpenAI-compatible proxy fallback.

A key feature is the deterministic visual direction pickers and a sandboxed iframe preview that lets you see the design output safely before exporting. Persistence is handled with SQLite, enabling reliable state management. Export formats include HTML, PDF, PPTX, and MP4, covering a broad range of presentation needs.

Technically, the stack is TypeScript-based, designed for extensibility and modularity. The local daemon orchestrates the agents, ensuring each step in the design process is controlled and reproducible. On Windows, where the ENAMETOOLONG error can occur for long command-line inputs, the system uses stdin and prompt-file adapters to work around this OS limitation.

What sets open design apart: composability, BYOK, and local orchestration

The standout technical aspect of Open Design is its decision to not bundle an AI agent but instead build a design engine that wires existing coding-agent CLIs into a layered skill stack. This BYOK architecture is not just a security feature but also a practical one: users can choose their preferred AI providers and update or swap CLIs without changing the core system.

The 31 composable skills form a modular prompt and task orchestration system. Each skill encapsulates a piece of the design workflow — from visual style selection to asset generation — allowing complex design tasks to be built from smaller, reusable components. This skill system also supports multi-dimensional self-critique, which means agents evaluate outputs across five dimensions to improve iteration quality.

The local daemon runs these agents in the context of real project folders, giving them Read/Write/Bash/WebFetch permissions. This integration with the real filesystem and shell environments is a powerful feature for realistic design workflows, but it also requires careful sandboxing. Open Design uses iframe sandboxes for previews to avoid unsafe code execution while still allowing dynamic content rendering.

Another tradeoff is that the UX depends on the quality and availability of the coding-agent CLIs you have installed. Since the system delegates agent functionality, any limitations or bugs in those CLIs will affect Open Design’s overall experience. However, this design avoids the bloat and maintenance overhead of bundling AI models, keeping the core system lightweight.

The system also includes a curated gallery of prompts and 72+ design systems, many hand-authored or product-grade, which provide a rich starting point for users. This focus on deterministic visual direction and reproducibility is a practical advantage for teams needing consistent brand-grade outputs.

Quick start with open design

git clone https://github.com/nexu-io/open-design.git
cd open-design
corepack enable
corepack pnpm --version   # should print 10.33.2
pnpm install
pnpm tools-dev run web

This quickstart sequence gets you the project locally, installs dependencies with pnpm, and runs the web interface in development mode. Since the system relies on scanning your PATH for coding-agent CLIs, make sure you have compatible agents installed beforehand.

Verdict: who should consider open design

Open Design is a solid choice for developers and teams who want a local-first, composable AI-powered design workflow without locking into a single AI provider or model. Its BYOK approach and modular skill system provide flexibility and control, and the sandboxed previews plus multi-format exports make it practical for real-world design projects.

That said, it assumes some familiarity with coding-agent CLIs and local development environments. The reliance on external agents means you must manage those dependencies yourself, and the Windows fallback for long CLI commands adds complexity.

If you want a design engine that integrates tightly with your existing AI coding agents and values deterministic, reproducible outputs, Open Design is worth exploring. It’s less suitable if you want a turnkey cloud-hosted design tool or prefer a single integrated AI model out of the box.

Overall, the repo shows an interesting architectural approach to AI-assisted design workflows that balances modularity, local control, and practical usability.

→ GitHub Repo: nexu-io/open-design ⭐ 15,552 · TypeScript