Skip to content
Docs

The two app model

The two app model is the split that lets Denote stay a thinking tool and Claude Code stay a building tool. Denote writes structured files to your project directory. Claude Code reads those files and generates the code. Both apps run at the same time, pointed at the same folder on disk.

Why the split exists

Most AI design tools try to do both jobs at once. They capture your idea and render the screen in the same motion. Structure and visuals collapse into a single output that is hard to unbundle.

Denote splits the two jobs across two tools so each one can stay honest.

The thinking tool is visual and structural. It shows objects, relationships, governance, page inventory, region wireframes. It lets you shape decisions.

The building tool is terminal-native and code-aware. It reads decisions, applies them against a real codebase, and produces files you can run.

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

What Denote owns

Denote owns the authoring side of the pipeline.

  • The six layers (Vision, Extract, Map, Structure, Layout, Plan).
  • The governance schema that maps signals to UI decisions.
  • The project settings, including the design system pointer.
  • The activity feed and the on-disk history of what has been written.

Everything Denote authors lives under design/ in your project folder. The files are plain JSON and Markdown. You can read them, edit them by hand, check them into git.

What Claude Code owns

Claude Code owns the building side of the pipeline.

  • Running skills (/vision, /extract, /map, /structure, /layout, /generate-plan) that update the design files.
  • Reading the design files and generating code.
  • Applying the governance schema as real constraints on the output.
  • Everything a terminal coding agent normally 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. There is no sync protocol, no paired session, no export step.

  1. You edit a layer in Denote. Denote writes the change to design/ immediately.
  2. You run a skill in the terminal. Claude Code reads design/, updates it, and logs the run to the activity feed.
  3. You switch to a different layer in Denote. Denote reads the updated file from disk and renders it.

The same loop works in reverse. If Claude Code rewrites a design file on its own, Denote picks up the change the next time you open that layer.

The recipe example

In the sample project (a recipe portion calculator), the loop looks like this.

  1. In Denote's Vision layer you write: "Home cook scales a recipe up or down by serving count. Save favorite scaling ratios per recipe."
  2. You type /extract in the embedded terminal. Claude Code reads design/vision.json, runs the extraction skill, and writes design/entities.json with Recipe, Ingredient, Serving, and ScalingRatio.
  3. You switch to the Extract layer in Denote. The four entities are there, rendered as cards.
  4. You type /map in the terminal. Claude Code reads design/entities.json, runs the mapping skill, and writes design/governance.json with pattern assignments and visual cues.
  5. You switch to the Map layer. The assignments are there.

At no point did you leave Denote to update Claude Code, or leave Claude Code to update Denote. Both tools have been watching the same folder the entire time.

What this enables

Reversibility. Every decision is a file on disk. If a skill does the wrong thing, you edit the file and move on. Nothing is 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. If someone else is going to build from your decisions, you send them the folder. They open Claude Code, point it at the folder, and start building. They do not need Denote.

Editing by hand. You can edit any design file in a code editor and Denote will pick up the change. The UI is a convenience, not a gatekeeper.

Where to next