Repository intelligenceRepositories
⌘K
Home / Repositories / nexu-io/open-design / Instruction Manual
Instruction Manual · Apple silicon · macOS Tahoe

nexu-io/open-design Instruction Manual

Local-first desktop design studio connecting coding agents to prototypes, dashboards, decks, images, HyperFrames video, design systems, plugins, and exports.

Beginner-friendlyCopy-paste examplesFirst-party sources checked
GitHubRepository profileInstallation Guide

What nexu-io/open-design is—in plain language

Local-first desktop design studio connecting coding agents to prototypes, dashboards, decks, images, HyperFrames video, design systems, plugins, and exports.

Mental model: This repository is primarily a desktop interface. Use menus and forms for ordinary work; Terminal commands are mainly for installation, diagnostics, and development.
InterfacesGUI, CLI, MCP, plugin
Primary languageTypeScript, JavaScript
Typical useUse agents to create/preview visual artifacts in a dedicated studio, persist DESIGN.md context, and export HTML/PDF/PPTX/MP4.

Your first 15 minutes

  1. Complete the linked Installation Guide and its verification step.
  2. Create a disposable test folder or use non-sensitive sample data.
  3. Run the small example below and observe what files, ports, or prompts appear.
  4. Read the result before approving writes, network calls, account access, or costs.
  5. Only then repeat the workflow with a real project.
Starter workflow
git clone https://github.com/nexu-io/open-design.git
cd open-design/deploy
cp .env.example .env
echo "OD_API_TOKEN=$(openssl rand -hex 32)" >> .env
docker compose up -d
# open http://127.0.0.1:7456
Open Installation GuideOpen upstream README

Complete indexed functionality map

Each card below corresponds to a component identified in the repository research. Open a component record for its path, purpose, capabilities, dependencies, risks, and relationships.

Upstream feature-by-feature guide

These capabilities are derived from the current first-party README and supporting documentation. Names follow upstream terminology so you can search the source documentation precisely.

Upstream capability

What is OpenDesign

Upstream treats this as a distinct part of nexu-io/open-design. In plain language, use this area when your task concerns what is opendesign. Begin with the documented default, test it on disposable input, and open the source section for its current options and limitations.

Upstream capability

Product tour

Upstream treats this as a distinct part of nexu-io/open-design. In plain language, use this area when your task concerns product tour. Begin with the documented default, test it on disposable input, and open the source section for its current options and limitations.

Upstream capability

Core pages

Upstream treats this as a distinct part of nexu-io/open-design. In plain language, use this area when your task concerns core pages. Begin with the documented default, test it on disposable input, and open the source section for its current options and limitations.

Upstream capability

Studio — many artifact types in one project

Upstream treats this as a distinct part of nexu-io/open-design. In plain language, use this area when your task concerns studio — many artifact types in one project. Begin with the documented default, test it on disposable input, and open the source section for its current options and limitations.

Upstream capability

Platform Compatibility

Upstream treats this as a distinct part of nexu-io/open-design. In plain language, use this area when your task concerns platform compatibility. Begin with the documented default, test it on disposable input, and open the source section for its current options and limitations.

Upstream capability

Demo

Upstream treats this as a distinct part of nexu-io/open-design. In plain language, use this area when your task concerns demo. Begin with the documented default, test it on disposable input, and open the source section for its current options and limitations.

Upstream capability

1 · Prototypes — web · desktop · mobile

Upstream treats this as a distinct part of nexu-io/open-design. In plain language, use this area when your task concerns 1 · prototypes — web · desktop · mobile. Begin with the documented default, test it on disposable input, and open the source section for its current options and limitations.

Upstream capability

2 · Live artifacts & dashboards

Upstream treats this as a distinct part of nexu-io/open-design. In plain language, use this area when your task concerns 2 · live artifacts & dashboards. Begin with the documented default, test it on disposable input, and open the source section for its current options and limitations.

Upstream capability

3 · Decks — magazine decks, weekly updates, pitches

Upstream treats this as a distinct part of nexu-io/open-design. In plain language, use this area when your task concerns 3 · decks — magazine decks, weekly updates, pitches. Begin with the documented default, test it on disposable input, and open the source section for its current options and limitations.

Upstream capability

4 · Images — gpt-image-2, ImageRouter, custom API

Upstream treats this as a distinct part of nexu-io/open-design. In plain language, use this area when your task concerns 4 · images — gpt-image-2, imagerouter, custom api. Begin with the documented default, test it on disposable input, and open the source section for its current options and limitations.

Upstream capability

5 · Video & HyperFrames — agent-native motion graphics

Upstream treats this as a distinct part of nexu-io/open-design. In plain language, use this area when your task concerns 5 · video & hyperframes — agent-native motion graphics. Begin with the documented default, test it on disposable input, and open the source section for its current options and limitations.

Upstream capability

Why OpenDesign

Upstream treats this as a distinct part of nexu-io/open-design. In plain language, use this area when your task concerns why opendesign. Begin with the documented default, test it on disposable input, and open the source section for its current options and limitations.

How to use the main workflows

1

Choose the smallest relevant function

Start with one capability card instead of asking the repository to do everything at once. This makes permissions, inputs, and output easier to understand.

2

Prepare a disposable input

Use a sample URL, copied repository, test document, or sandbox account. Keep production credentials and irreplaceable files out of the first run.

3

Run, observe, and stop

Watch Terminal output or the host application's activity view. If the behavior differs from the README, stop with Control + C or cancel inside the host before retrying.

4

Inspect the result

Check generated files, diffs, API responses, logs, or previews. Never assume “command finished” means the result is correct.

5

Save a repeatable recipe

Record the working command and non-secret configuration in your project's README. Store secrets in the documented environment file or password manager.

Copy-paste recipes from upstream documentation

These examples are selected from the repository's first-party documentation. Replace obvious placeholders, keep quotation marks intact, and run them only in the context indicated by the surrounding explanation.

🐳 Run with Docker
git clone https://github.com/nexu-io/open-design.git
cd open-design/deploy
cp .env.example .env
echo "OD_API_TOKEN=$(openssl rand -hex 32)" >> .env
docker compose up -d
# open http://127.0.0.1:7456
Building a plugin
od plugin scaffold --id my-plugin --title "My Plugin"   # generate the skeleton
od plugin validate ./my-plugin                          # check manifest / file layout
pnpm guard && pnpm --filter @open-design/plugin-runtime typecheck

Configuration, accounts, and files

Configuration files

None documented

A configuration file changes behavior without changing source code. Make one change at a time and keep a backup before editing JSON, TOML, YAML, or environment files.

Important directories

None documented

Paths identify where the relevant implementation or generated files live. Paths beginning with ~ are inside your home folder.

Credentials

None documented

Prefer temporary, least-privileged credentials. Never commit .env, tokens, cookies, private keys, or session exports.

External services

None documented

Check pricing, data retention, rate limits, and account permissions before enabling optional integrations.

Safe operating habits

  • Use test data first and keep a current backup or Git commit.
  • Read commands before pasting. A README is useful evidence, not a substitute for judgment.
  • Review agent-generated file changes with git diff before committing.
  • Keep local services bound to 127.0.0.1 unless you intentionally secure and expose them.
  • Do not give plugins or MCP servers broader filesystem, browser, GitHub, or cloud access than their current task requires.
  • Confirm API costs and model names before running large batches.
  • Stop and investigate repeated authentication failures instead of pasting a token into multiple places.

Reference and source trail

The manual reflects first-party files checked on August 18, 2026. It explains the indexed repository rather than promising that every optional third-party integration is available or safe.