Skip to content
Docs

The two app model

Denote writes structured files. Claude Code reads them and generates code. Both apps run at the same time, pointed at the same folder on disk. Denote stays a thinking tool; Claude Code stays a building tool.

Why the split

Most AI design tools try to do both jobs at once — capture your idea and render the screen in the same motion. Structure and visuals collapse into one black-box output that's hard to unbundle.

Denote splits them so each tool stays honest:

  • Thinking tool — visual and structural. Shows objects, relationships, governance, screen inventory, chip compositions. Lets you shape decisions.
  • Building tool — terminal-native and code-aware. Reads decisions, applies them against a real codebase, produces files you can run.

Neither tool pretends to do the other's job. Denote doesn't render code. Claude Code doesn't ask you to fill out wireframes.

What Denote owns

The authoring side of the pipeline:

  • The four layers (Vision, Ontology, Architecture, Screens) plus the Spec hand-off.
  • The governance schema that maps signals to UI decisions.
  • The activity feed and the on-disk history of what has been written.

Everything Denote writes lives under design/ in your project folder — plain JSON and Markdown. Read it, edit it by hand, commit it to git.

What Claude Code owns

The building side:

  • Running skills (/vision, /ontology, /architecture, /screens, /spec) that update the design files.
  • Reading the design spec — usually from a separate Claude Code session running in the target project — and generating code.
  • Applying the governance schema as real constraints on the output.
  • Everything a terminal coding agent does: running the dev server, editing files, executing tests.

Claude Code runs inside Denote as an embedded terminal, and it also runs outside Denote on its own when you want it to. The project files are the same either way.

How they share

The filesystem is the integration layer. No sync protocol, no paired session, no export step.

CLAUDE.md at the project root tells Claude Code how to behave:

  • Design mode — Claude is a thinking partner. Edits design/*.json only; doesn't write code.
  • Build mode — Claude is your build partner. Same folder, same files; different rules.

Switch from the top bar. See Design and Build mode.

The loop:

  1. Edit a layer in Denote → Denote writes to design/ immediately.
  2. Run a skill in the terminal → Claude Code reads design/, updates it, logs to the activity feed.
  3. Switch layers in Denote → it reads the updated file from disk and renders.

Reverse works too. If Claude Code rewrites a design file on its own, Denote picks it up next time you open that layer.

[Screenshot TODO: split-screen showing Denote on the left with a layer open, the embedded terminal on the right mid-skill, and a Finder window behind showing the files on disk updating.]

What this enables

  • Reversibility — every decision is a file. If a skill does the wrong thing, edit the file and move on. Nothing locked inside app state.
  • Version control — your project is a folder. git init, commit, branch, diff. The design history is the commit history.
  • Hand-off — send someone the folder. They open Claude Code, point it at it, start building. They don't need Denote.
  • Edit by hand — change any design file in a code editor; Denote picks it up. The UI is a convenience, not a gatekeeper.

Where to next