'OpenDesign + OpenCode: Building a Local-First Design Operating System Inside [post] deterministic
A deep technical guide to building a local-first design and development
OpenDesign + OpenCode: Building a Local-First Design Operating System Inside Your Terminal
*June 8, 2026 · Daniel Kliewer*
---
There is a strange contradiction at the center of modern software development.
We have coding agents capable of writing React applications, deploying infrastructure, refactoring monoliths, generating tests, orchestrating CI/CD pipelines, and reasoning across entire repositories. We have local models that can run on consumer hardware. We have Model Context Protocol (MCP) servers that allow AI systems to interact with structured tools and data. We have open-source ecosystems that increasingly rival commercial offerings.
Yet most development workflows still require a human to manually bridge the gap between design and implementation.
A designer creates something in Figma. A screenshot gets exported. The screenshot gets pasted into Cursor, Claude, OpenCode, Codex, or another coding agent. The model attempts to reconstruct what it sees. The developer fixes inconsistencies. The cycle repeats.
The entire workflow depends on moving information between systems that cannot directly communicate.
**OpenDesign and OpenCode represent a fundamentally different approach.**
Instead of treating design as a screenshot problem, they treat design as structured data. Instead of forcing an AI agent to infer your design system from images, OpenDesign exposes design systems, design tokens, component definitions, assets, skills, and project artifacts through a machine-readable interface.
When OpenCode is connected to OpenDesign through MCP, your coding agent no longer generates code from vague descriptions. It generates code from the source of truth.
The result is something much more interesting than another AI coding assistant.
It is the beginning of a **local-first design and development operating system**.
---
Table of Contents
- [Understanding the Architecture](#understanding-the-architecture)
- [The Missing Layer in AI Development](#the-missing-layer-in-ai-development)
- [OpenDesign as a Design Operating System](#opendesign-as-a-design-operating-system)
- [Installing OpenDesign](#installing-opendesign)
- [Installing OpenCode](#installing-opencode)
- [Method 1: Automated Skill-Based Installation](#method-1-automated-skill-based-installation)
- [Verifying Integration](#verifying-integration)
- [What
od mcp install opencodeActually Does](#what-od-mcp-install-opencode-actually-does) - [Installing Everything From Scratch](#installing-everything-from-scratch)
- [Starting the Daemon](#starting-the-daemon)
- [MCP Wiring Reference](#mcp-wiring-reference)
- [Environment Variables](#environment-variables)
- [Docker Deployment](#docker-deployment)
- [Building a Skill From Scratch](#building-a-skill-from-scratch)
- [Understanding MCP](#understanding-mcp)
- [The Sovereign Design Stack](#the-sovereign-design-stack)
- [Troubleshooting](#troubleshooting)
---
Understanding the Architecture
Many developers initially misunderstand OpenDesign.
They assume it is another coding agent. It isn't.
Likewise, OpenCode is not a design tool.
The two systems solve different problems.
- **OpenCode** is an *agent runtime*.
- **OpenDesign** is a *design orchestration layer*.
Together they create a system where design knowledge becomes accessible to coding agents.
High-Level Architecture
┌──────────────────────────────────────────────────────┐
│ OpenDesign Daemon │
│ │
│ ┌──────────┐ ┌──────────┐ ┌───────────────────┐ │
│ │ Skills │ │ Design │ │ MCP Server │ │
│ │ (259+) │ │ Systems │ │ (stdio-based) │ │
│ └──────────┘ └──────────┘ └────────┬──────────┘ │
│ │ │
└────────────────────────────────────────┼──────────────┘
│
▼
┌─────────────────────┐
│ OpenCode CLI │
│ │
│ Coding Agent Loop │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ LLM Backend │
│ OpenAI/Ollama/Qwen │
│ Claude/Gemini/etc │
└─────────────────────┘
The key insight is that **OpenDesign does not attempt to replace your coding agent**.
Instead, it acts as an **adapter layer** that augments existing coding agents with design intelligence.
What Each System Is Responsible For
**OpenDesign's job:**
- Manage design systems
- Manage skills
- Manage artifacts
- Manage project exports
- Expose MCP resources
- Discover supported coding agents
- Feed structured design context into those agents
**OpenCode's job:**
- Reason about tasks
- Execute tools
- Edit files
- Run commands
- Manage context windows
- Generate code
This separation of concerns is one of OpenDesign's most elegant design decisions. OpenDesign focuses on *design*. OpenCode focuses on *execution*.
---
The Missing Layer in AI Development
A coding agent understands:
- Source code
- Documentation
- Terminal output
- Configuration files
- Build systems
A coding agent does **not** inherently understand:
- Typography hierarchies
- Brand systems
- Color palettes
- Design tokens
- Layout conventions
- Visual identity
Historically developers solved this by embedding screenshots into prompts. That approach works, but it scales poorly. Screenshots become stale. Prompts become larger. Consistency becomes harder to maintain.
OpenDesign solves the problem by making design information **queryable**.
Interpretation vs. Retrieval
Instead of writing this in a prompt:
> "Use the blue color from our design system."
The agent can retrieve structured data:
json
{
"primary": "#0066FF"
}
Instead of describing spacing:
> "Use the spacing system from our design docs."
The agent can retrieve:
json
{
"spacing-sm": "8px",
"spacing-md": "16px",
"spacing-lg": "24px"
}
This distinction may seem minor. It is not.
- One approach relies on **interpretation**.
- The other relies on **retrieval**.
Retrieval scales. Interpretation eventually breaks.
---
OpenDesign as a Design Operating System
The best way to think about OpenDesign is not as a design tool. It is a **design operating system**.
Its core subsystems include:
1. Design Systems
OpenDesign ships with over **one hundred production-grade design systems**. These contain:
- Typography systems
- Color systems
- Accessibility standards
- Component libraries
- Layout rules
- Brand conventions
Rather than repeatedly prompting agents about these rules, OpenDesign stores them as reusable artifacts that any MCP-connected agent can query by name.
2. Skills
Skills are one of OpenDesign's most important concepts.
A **skill** is a reusable unit of expertise. Instead of prompting:
> "Create a modern SaaS landing page using accessibility best practices and responsive layouts."
every single time, a skill already encodes that expertise.
A canonical skill on disk looks like this:
text
skill/
├── SKILL.md
├── assets/
└── references/
A skill can provide:
- Behavioral guidance
- Workflow instructions
- Design conventions
- Example assets
- Reference documentation
OpenDesign currently ships with **hundreds of skills** spanning:
- Prototyping
- Design systems
- Exports
- Slides
- Images
- Video generation
- Presentation workflows
- Component generation
The coding agent loads expertise instead of recreating it.
3. MCP Server
The MCP server is arguably OpenDesign's most important architectural component. It allows external agents to access