Skip to content

references.md

Latest commit

 

History

History
203 lines (167 loc) · 14 KB

references.md

File metadata and controls

203 lines (167 loc) · 14 KB
Raw

References

Parent: spec.md

Every external project this spec leans on. Three questions per entry: what is it, what do we borrow, and what do we deliberately not take.

Primary references

Anthropic Claude Design

  • What it is: Anthropic's closed-source AI design product. Released 2026-04-17. Powered by Opus 4.7. Web-only (claude.ai). Generates prototypes, wireframes, decks, marketing pages, complex prototypes with voice/video/3D/shaders.
  • Why it matters to us: Defines the category. Its viral moment (~60M X impressions week 1) proves the market.
  • What we borrow: The high-level value prop — "natural language → editable visual design." Feature inspiration for modes (prototype, deck, marketing). UI ideas around inline editing and custom sliders.
  • What we don't: Closed source. Anthropic-only models. No self-hosting. Paid tiers (Pro/Max/Team/Enterprise) only. We are not trying to be a drop-in clone; we are an open substrate for the same category.

Open CoDesign (OpenCoworkAI)

  • Why it matters: Direct competitor; most overlap with what we're building.
  • What we borrow:
    • UI concepts: comment mode (click-to-pin element edits), tweak sliders (agent-emitted parameters), multi-frame preview (desktop/tablet/phone).
    • Sandboxed iframe preview (<iframe sandbox="allow-scripts"> with vendored React 18 + Babel standalone for JSX).
    • Export pipeline shape (HTML/PDF/PPTX/ZIP/MD).
  • What we don't:
    • Electron as the product runtime — our product UI remains the shared Next.js web app; apps/desktop and apps/packaged provide a thin Electron host around the same daemon/web sidecars.
    • Bundled agent on pi-ai — we delegate to the user's existing CLI.
    • Proprietary skill format (TypeScript modules compiled into the app) — we use Claude Code's SKILL.md so third-party skills drop in.
    • SQLite blobs for artifact bytes — generated files remain on disk while daemon SQLite owns project and metadata state.
    • Sole focus on UI panels — we add a first-class Design System product surface and DESIGN.md contract.

multica (multica-ai)

  • What it is: Open-source "managed agents platform." Frontend: Next.js 16. Backend: Go + Chi + WebSocket. DB: PostgreSQL + pgvector. Local daemon auto-detects CLIs on PATH: Claude Code, Codex, OpenClaw, OpenCode, Hermes, Gemini, Pi, Cursor Agent. Assigns work via a web board view; agents execute; WebSocket streams progress.
  • Why it matters: They already solved the "detect and wrap local code agents" problem.
  • What we borrow:
    • PATH-scan + config-dir probe detection strategy.
    • Local daemon + WebSocket topology (daemon on user's machine, thin web client).
    • Agent catalog (our P0–P2 list maps closely to theirs).
    • Workspace/local skill import and agent-scoped skill attachment model.
  • What we don't:
    • Go backend + PostgreSQL — overkill for our scope; Node daemon + filesystem is enough.
    • Team / board / issue-assignment model — not our domain.
    • pgvector — we don't embed anything in MVP.

OpenHuman (tinyhumansai)

  • What it is: Open-source personal AI assistant with many integrations, auto-fetch into a memory tree, local editable knowledge, and a TokenJuice-style compression layer before LLM use.
  • Why it matters: It is the clearest reference for "connect sources once, then the agent wakes up with compressed context already available."
  • What we borrow:
    • Connector-driven ingestion as a first-class loop, not a prompt the user rewrites each time.
    • Editable local memory tree rather than opaque vector-only recall.
    • Token compression as an optional stage before agent context injection.
  • What we don't:
    • General personal-assistant scope, messaging/voice/meeting participation, and bundled subscription/model routing.

Hermes Agent (Nous Research)

  • What it is: Self-improving agent with persistent memory, skills created from experience, skill improvement during use, scheduled automations, and a large skill hub.
  • Why it matters: It turns "agent learns from work" into a product loop instead of a side effect.
  • What we borrow:
    • Closed learning loop: experience -> memory or skill proposal -> future run.
    • Scheduled automations that can deliver across surfaces.
    • Explicit compression and usage inspection controls.
  • What we don't:
    • Owning the user's entire agent runtime, messaging gateway, or model/provider layer.

GenericAgent (lsdefine)

  • What it is: Minimal self-evolving autonomous agent framework that crystallizes solved tasks into a personal skill tree for direct reuse.
  • Why it matters: It names the core loop OD needs for design work: solve once, verify, save the execution path, and recall it with less context next time.
  • What we borrow:
    • Skill crystallization from successful tasks.
    • Layered memory and direct recall to reduce prompt size.
    • A bias toward small composable primitives instead of a heavy agent framework.
  • What we don't:
    • Broad uncontrolled desktop authority. OD keeps daemon, connector, filesystem, and review gates explicit.

cc-switch (farion1231)

  • What it is: Tauri desktop app for managing five CLI tools (Claude Code, Codex, Gemini CLI, OpenCode, OpenClaw). Provider management, MCP server config, skills install, session browsing. SQLite at ~/.cc-switch/cc-switch.db. Skills dir at ~/.cc-switch/skills/ with symlinks into each agent's config dir. 50+ provider presets.
  • Why it matters: Shows exactly how to live beside multiple code-agent CLIs without stepping on their config.
  • What we borrow:
    • The idea of one discoverable library serving several agent runtimes. Open Design implements that boundary through its own registries and makes a real CWD-local copy of active skill resources for each run; it does not symlink bundles into every agent's global skills directory.
    • Knowledge of per-agent config dir locations (~/.claude/, ~/.codex/, …).
    • "Provider presets" idea — a curated list we can ship so users don't have to hand-enter endpoint URLs for OpenAI-compatible relays.
  • What we don't:
    • Tauri / desktop app — not our shape.
    • Provider-switching as core feature — we defer that to the underlying agent. If a user wants to switch providers inside Claude Code, they use Claude Code's config, not ours.
    • Tray icon / system integration — out of scope.

awesome-claude-design (VoltAgent)

  • Historical ecosystem: the project exposed 68 DESIGN.md files and a nine-heading baseline when this reference was first recorded.
  • Related URLs: claude.ai/design, getdesign.md, Discord community
  • Why it matters: Defines the de-facto portable design-system format for AI agents.
  • What we borrow:
    • Portable DESIGN.md prose remains a compatibility floor: a legacy folder containing only that file can still be discovered and used.
    • The original nine headings remain a useful historical sample, not a fixed authoring schema. Current repository packages use manifest.json, DESIGN.md, tokens.css, and optional rich component/source/preview resources; migrated packages need substantive coverage without prescribed heading names or order.
  • What we don't:
    • Treating one upstream list as the current catalogue boundary. The bundled catalogue now contains 151 packages drawn from multiple attributed sources and Open Design-authored systems.
    • Their Discord / community layer — not our product.

guizang-ppt-skill (op7418)

  • What it is: A Claude Code skill producing magazine-style, horizontal-swipe web decks. Structure: SKILL.md + assets/template.html + references/{components,layouts,themes,checklist}.md. 6-step workflow. Single-file HTML output with embedded CSS/WebGL. Keyboard/scroll/touch navigation.
  • Why it matters: Reference implementation of a high-quality Claude skill and the source of our bundled guizang deck template.
  • What we borrow:
    • The workflow and assets are bundled under design-templates/guizang-ppt/ with the upstream license preserved and Open Design metadata/file-handoff integration applied.
    • Skill directory convention (assets/ + references/ + SKILL.md) as the pattern we document for skill authors.
    • The "6-step workflow + quality-checklist rubric" pattern for authoring new skills.
  • What we don't: We do not require the retired od skill add flow; the rendering template ships in the catalogue and can still be consumed as a portable SKILL.md bundle.

Secondary references (format / protocol / UI ideas)

Project Relevance
Claude Code skills docs Source of the SKILL.md format we adopt
Cursor rules Historical format inspiration only; the current Cursor Agent adapter receives Open Design's composed prompt over stdin and uses the same CWD-local resource staging as other runtimes
Reveal.js / Marp Reference for deck HTML navigation patterns
Shadcn/ui Component and registry reference; the product shell now uses repository-owned primitives from @open-design/components
Vercel AI SDK Historical API-fallback exploration; current BYOK providers run through the OpenCode adapter rather than a direct SDK adapter
Puppeteer Reference for template/skill-owned browser rendering; core desktop PDF export uses Electron printToPDF or the screenshot/PDF pipeline
pptxgenjs PPTX export engine
chokidar Ref-counted project-file watching; skill/template registries rescan on listing requests instead

Compatibility & differentiation matrix

Dimension Claude Design Open CoDesign multica cc-switch OD
Open source ❌ ✅ ✅ ✅ ✅
Primary form factor Web (hosted) Electron Web + Go daemon Tauri Next.js web + Node daemon
Vercel-deployable ❌ ❌ ❌ ❌ ✅
Runs local-only ❌ ✅ ✅ ✅ ✅
Generates design artifacts ✅ ✅ ❌ (general coding) ❌ ✅
Uses existing code agent — (owns it) ❌ ✅ ✅ ✅
Supports Claude Code skills (SKILL.md) — ❌ ✅ ✅ ✅
DESIGN.md as first-class ❌ ❌ — — ✅
Deck mode / PPTX export ✅ ✅ ❌ ❌ ✅ (via skill)
Template gallery ✅ ✅ (15) ❌ ❌ ✅
Design-system authoring mode ❌ ❌ ❌ ❌ ✅

The two empty-column crossings where OD lights up and others don't: Vercel-deployable + design-system authoring, and uses existing code agent + first-class DESIGN.md. That's the niche.

What we explicitly don't borrow (and why)

  • Electron as a separate product architecture. Open Design now ships thin desktop and packaged Electron hosts, including signing/update work, but the product UI remains the same Next.js web app and daemon rather than a second desktop-only implementation.
  • SQLite for artifacts (from Open CoDesign and cc-switch). Plain files + JSONL history are reviewable in git, trivially portable, and match the "skills are files" ethos.
  • Bundled model router (pi-ai from Open CoDesign). The user's code agent already routes. Two routers is worse than one.
  • PostgreSQL + pgvector (from multica). We don't embed anything in MVP. When we do, SQLite + sqlite-vec is enough for single-user scale.
  • Board / issue model (from multica). Off-brand for a design tool.

These boundaries keep external integrations from replacing the shared web, daemon, filesystem, and agent-runtime contracts.

Living references

This file is maintained. When we add an adapter or borrow a pattern from a new upstream, add it here with the same three-question format. When upstream licensing or direction changes materially, flag it here and cross-link from spec.md.