Technical Briefing: open-design

The Problem

The repository comprises 12 self-contained projects spanning design systems, plugins, desktop applications, and deployment tooling without a unifying architecture. Teams evaluating this as a design engine face integration friction from disconnected codebases, varying dependency states (10 packages pinned 1-6 major versions behind current), and CI configurations that run checks without executing test assertions. The health audit identified 9 findings including critical secret exposure in workflow files and unpinned GitHub Actions versions.

What This Does

Open Design functions as a local-first desktop app (Electron-based) generating web prototypes, dashboards, decks, images, and video via AI harnesses. The codebase organizes around apps/ (4284 files, 2832 code files), design-systems/ (4040 files, 3 code files, 927 data files), and plugins/ (1815 files, 40 code files, 614 data files). Core agent protocol handling resides in apps/daemon/src/agent-protocol/ with entry points at index.ts, acp/index.ts, core/index.ts, dsh-profile/index.ts, and pi-rpc/index.ts. Design templates live in design-templates/ (747 files), while skills and clipper modules occupy skills/ (356 files) and clipper/ (48 files) respectively. The packages/ directory (330 files) contains shared utilities, and tools/ (227 files) provides auxiliary build and release scripts.

How It Is Wired

Execution begins at the daemon entry points in apps/daemon/src/agent-protocol/. The acp/index.ts and core/index.ts files orchestrate agent communication, with dsh-profile/index.ts specifically configuring DeepSeek Harness (dsh) integration. Agent protocol messages flow through pi-rpc/index.ts. The apps/desktop/package.json and apps/daemon/package.json define the desktop and backend runtimes respectively, both using pnpm. Dockerfiles exist at the root for containerized deployment. No single hub connects all 12 projects; data moves through explicit protocol messages between the daemon and harness runtimes, and the plugin system in plugins/ registers capabilities via SKILL.md files in skills/. The design-systems layer (design-systems/) stores brand-grade DESIGN.md specifications but contains only 3 code files, indicating most content is data-driven rather than engineered.

How To Use It

Setup

git clone https://github.com/moses-y/open-design
cd open-design
pnpm install

Configuration Environment variables and keys are expected in apps/landing-page/.env.example. The DeepSeek Harness integration requires dsh runtime configuration; see apps/daemon/src/agent-protocol/dsh-profile/index.ts for profile setup. OAuth credentials for Google Search Console appear in .github/workflows/blog-indexing-on-deploy.yml — these must not be committed or exposed in forks.

Running it

# Desktop app
pnpm run dev --filter@desktop

# Daemon/agent backend
pnpm run start --filter@daemon

Real-World Use

A product team can prototype a landing page by cloning the design-templates/ directory, modifying HTML/TSX files, and running the daemon to generate live preview in a sandboxed iframe. The plugins/ system allows swapping AI harnesses — replacing DeepSeek Harness (dsh) with Claude Code or OpenCode via skill YAML configs in skills/. Export generates HTML, PDF, PPTX, or MP4 via the apps/daemon build pipeline. For design system updates, edit DESIGN.md files in design-systems/ and trigger the preview validation scripts in tools/.

Code Health & Issues

The static analysis found 9 issues across the repository:

  • [CRITICAL] Keep secrets out of workflows a fork can trigger — .github/workflows/blog-indexing-on-deploy.yml contains GSC_OAUTH_CLIENT_ID, GSC_OAUTH_CLIENT_SECRET, GSC_OAUTH_REFRESH_TOKEN, GSC_SERVICE_ACCOUNT_KEY; contributor-controlled input reaches a job holding publish credentials.
  • [HIGH] Pin third-party GitHub Actions to commit SHAs — pnpm/action-setup@v5 and peter-evans/create-pull-request@v8 use version tags that can move.
  • [HIGH] Upgrade pinned dependency with published advisory — postcss@8.5.15 has CVE-2026-73646; the pinned version is the one that installs.
  • [HIGH] Make CI invoke the test suite — 1792 test files exist but no test command runs in the 2 Azure Pipelines workflows read.
  • [HIGH] Open pull requests instead of pushing to default branch — bake-plugin-previews-release.yml uses git push origin which authenticates as github-actions[bot].
  • [MEDIUM] Enable Dependabot or Renovate — 27 manifests with no update bot configured.
  • [MEDIUM] Gate pull requests on dependency vulnerability scan — no dependency scan in CI.
  • [MEDIUM] Set persist-credentials: false on checkout — .github/workflows/blog-indexing-on-deploy.yml keeps the token; dependencies install with it.
  • [MEDIUM] Review install lifecycle script — postinstall in package.json files could fetch binaries from URLs.

The Bottom Line

This repository is a portfolio of 12 independent projects rather than a unified framework. The design-system and plugin layers offer tangible value for teams needing composable design tools with AI harness integration, particularly the DeepSeek Harness (dsh) support. However, the dependency obsolescence (10 packages 1-6 major versions behind), critical secret exposure in CI workflows, and CI that validates nothing make it unsuitable for production use without remediation. Teams comfortable auditing and fixing CI hygiene, pinning dependencies, and operating within a multi-project structure can extract value; others should look for a more opinionated, maintained design platform.