Open Design vs. bare Claude Code

A natural question once you understand OD: if Claude Code can read ~/.claude/skills/, write files, run TodoWrite, and shell out — why isn't running bare Claude Code in a project directory equivalent to using OD? This file answers it carefully.

1. The framing matters

OD does not compete with Claude Code. It wraps Claude Code (or any of 11 other CLIs). The README is upfront: "We don't ship an agent — the strongest coding agents already live on your laptop. We wire them into a skill-driven design workflow." (README.md:36).

So the real comparison is "OD around Claude Code" vs "bare Claude Code" — not OD vs Claude Code as alternatives.

2. What bare Claude Code already does

Reads Read, writes Write, edits Edit, runs Bash, plans with TodoWrite, fetches with WebFetch.
Reads ~/.claude/skills/<id>/SKILL.md natively — the skill convention OD adopts (docs/skills-protocol.md:7-8 calls this "compatibility promise").
Has its own permission system (--allowed-tools, --permission-mode).
Streams output as line-delimited JSON via --output-format stream-json (docs/agent-adapters.md:127-131).

So in a terminal, with the OD skills symlinked into ~/.claude/skills/, Claude Code can write the HTML for a deck. The task is reachable.

3. What you lose without OD

Capability	Where it lives in OD	Why bare Claude Code can't do it
Discovery form on turn 1 + 5 deterministic directions	`apps/daemon/src/prompts/discovery.ts:34-101`, `prompts/directions.ts:53-184`	Nothing forces this turn shape. Bare CC sometimes asks, sometimes freestyles. Palettes are improvised, not bound from a curated library.
`<question-form>` rendered as a real form	`apps/web/src/components/QuestionForm.tsx`	A terminal can't render a form. You see XML and have to copy-paste answers. The structured-input UX is a UI feature, not a model feature.
Sandboxed iframe preview with hot reload	`apps/web/src/runtime/srcdoc.ts`, `react-component.ts`	You'd open the HTML in a browser tab and refresh manually. No comment mode. No deck navigation. No live update on writes.
Comment-mode → surgical edit	`apps/web/src/comments.ts` (DOM snapshot) + commentAttachment round-trip	Bare CC has no DOM-snapshot capture, no way to target a specific element in a re-prompt. You'd describe what you want changed in prose.
Anti-AI-slop linter feeding findings back	`apps/daemon/src/lint-artifact.ts` (980 lines, 9 P0 patterns)	The agent never learns it just shipped Tailwind indigo or a left-accent card. The model writes; nobody checks; the loop never closes.
Cross-agent fallback (12 CLIs + BYOK)	`apps/daemon/src/agents.ts` (`AGENT_DEFS`, ~750 lines)	Bare Claude Code is one agent. If your team standardised on Cursor or Codex, it doesn't help.
129 design systems threaded into every generation	`prompts/system.ts:130-134`, `apps/daemon/src/design-systems.ts`	Claude Code has skills; it doesn't have design system as a separate axis layered into every system prompt with section pruning, swatch extraction, and showcase rendering.
Craft references (`od.craft.requires`)	`apps/daemon/src/craft.ts`, `prompts/system.ts:136-144`	A skill-level concept that sits between brand tokens and skill workflow. Not in Claude Code's skill protocol — you can't say "this skill needs anti-AI-slop + typography rules" and have those concatenate in.
Deck framework as enforced contract	`prompts/deck-framework.ts:38-374`	Bare CC writes its own scaling/nav/print logic each time, often re-introducing bugs. OD pins a verbatim skeleton with 9 explicit drift modes to avoid.
Project persistence (conversations, todos, tabs, deployments)	`apps/daemon/src/db.ts` (941 lines)	Claude Code has session logs; not a queryable project model with tabs, comments, and per-conversation message history.
Unified media generation across providers	`prompts/media-contract.ts`, `apps/daemon/src/media.ts` (1,690 lines)	Claude Code can shell out, but somebody has to be the dispatcher behind the shell call — that's `od media generate`, which routes to OpenAI / Volcengine / Grok / HyperFrames.
Vercel deploy from the UI	`apps/daemon/src/deploy.ts` (616 lines)	Claude Code writes files; doesn't upload them, doesn't rewrite asset paths, doesn't poll for deployment readiness.
Persisted message replay	`db.ts` (`messages.events_json`)	Claude Code's session replay is per-session in the terminal. OD persists every emitted event so the browser can reconnect mid-run.

4. What you could replicate by hand

Roughly the skill workflow layer. With effort:

Symlink skills/ into ~/.claude/skills/.
Copy the discovery prompt body into ~/.claude/CLAUDE.md or a project root CLAUDE.md.
Copy craft/anti-ai-slop.md into the same.
Run claude in a project directory with the skills argv ready.

You'd get question prompts (as terminal text, not forms), a TodoWrite plan, and an HTML file. About 40% of OD's value is reachable this way if you're a disciplined Claude Code user.

What you cannot replicate without rebuilding it:

The iframe preview pipeline (apps/web/src/runtime/).
Comment mode for surgical edits (apps/web/src/comments.ts).
The linter feedback loop (apps/daemon/src/lint-artifact.ts + renderFindingsForAgent).
Cross-agent dispatch (apps/daemon/src/agents.ts).
The <question-form> UX (terminal can't render forms).
Project persistence beyond Claude Code's own session logs.
Vercel deploy.
Media generation across multiple providers.

That's the other ~60%, and it's the part that turns "the agent can write some HTML" into "I can iterate on a real design with a designer's workflow."

5. The conceptual analogy

OD is to Claude Code what an IDE is to a compiler.

Compiler: takes source, produces a binary. Can do the task.
IDE: gives you syntax highlighting, navigation, refactoring, debugging, build profiles, integrated tests, deployment, source control UI — the workflow around the compiler.

You can ship software with gcc from the command line. People do. But for most engineers most of the time, the IDE is what makes the work happen.

Same shape: bare Claude Code can write HTML for a deck. But a designer iterating on a deck wants iframe preview + comment mode + direction picker + linter feedback + "tomorrow my todos and open files are exactly where I left them."

6. Why this is a sound bet

OD's central thesis (docs/agent-adapters.md:7-9):

"The code agent space has already converged on a few strong implementations (Claude Code, Codex, Devin for Terminal, Cursor Agent, Gemini CLI, OpenCode, OpenClaw). Reimplementing another one is worse than just talking to all of them."

If you accept that — and the evidence is on its side — then OD's value is precisely not in the agent. It's in the apparatus: the prompt stack, the UI, the linter, the persistence, the cross-agent dispatch. Everything that turns a general-purpose coding agent into a designer-grade tool.

7. Verdict

Question	Answer
Can bare Claude Code do the task (write a deck HTML file)?	Yes.
Can bare Claude Code deliver the product (iterate visually, catch AI-slop, persist project state, work cross-agent)?	No.
Is OD a thin wrapper?	No — `prompts/`, `lint-artifact.ts`, `comments.ts`, `media.ts`, `agents.ts` together are several thousand lines of substantial integration work.
Should OD ship its own agent?	The team explicitly says no. The bet is that talking to all of them is cheaper than reinventing one.

So: Claude Code could do the task. It couldn't deliver the product. That distinction — between agent capability and product experience — is the whole reason OD exists.