Your design shouldn’t live
outside your codebase.

Caret gives your repo a design layer: real React in .caret/, rendered live on a canvas you can click and edit. Your app’s source stays untouched until you sync.

Free forever · runs on your machine · no account

caret
.caret/pages/chair/index.tsx

Two sources of truth, and neither one is right.

  • The mockup and the build stopped agreeing in week two.

    Nobody decided which one wins. Everyone just learned which file not to trust.

  • You fixed that spacing last month.

    It came back with the next generated change, and you fixed it again, and you are not certain it will hold this time either.

  • Describing a visual change takes longer than making it.

    Three sentences about the padding on the second card, and it still comes back wrong, because words were never the right tool for pointing at something.

  • The design file is true right up until the first hotfix.

    After that it is a picture of something that used to be true, and everyone in the room knows it.

Your design is the code. Not a picture of it, not a file that drifts.

It lives in your repo, in git, reviewable in a pull request. So a fix you make once is still there tomorrow, instead of being regenerated away the next time you ask for something.

Design lived beside the repo

  • A file in a design tool
  • Vector objects and layer trees
  • Versioned by whoever remembered
  • Rebuilt by hand to ship it

Design lives in the repo

  • Its own directory, .caret/
  • Real .tsx you can read and diff
  • Versioned by git, like everything else
  • Synced into your app when you say so

Every one of these ends in a file in .caret/.

The rail is the file. Each stop is another way to change it.

What you stop doing.

  • Stop building the same screen twice.

    Once in a design tool where it looked right, once in code where it had to work. Caret deletes the first one.

  • Stop watching a fix get regenerated away.

    Your changes are files in git, not context in a chat window. Next week they are still there.

  • Stop describing a button in a paragraph.

    Point at the thing. Paint over the region you mean. The agent gets the exact elements, not your best attempt at words.

  • Stop letting an agent invent your spacing.

    Caret writes your tokens into AGENTS.md, CLAUDE.md and .cursor/rules, and keeps them current.

Same repo. Its own room.

Design and app code are both tracked, in one project, and Caret only ever writes to one of them on its own.

your-project/
  • .caret/the design layer Caret writes to
    • pages/each page, as real React
    • components/
    • tokens/colour, type, spacing, radius
    • flows/
    • assets/
  • src/your app, untouched until you sync
  • package.json
  • .git/tracks both
  1. It takes one directory.

    Open a folder and Caret creates .caret/ inside it. Nothing else in your project is read from or written to. Your build, your routes and your business logic are not in the blast radius of an experiment.

  2. You design in code, not in objects.

    A page is a .tsx file. A token is a value. Clicking the canvas edits those files, so every design decision arrives as a line someone can read in a diff. An agent can read it too, without an export step.

  3. Sync is a thing you choose.

    When a design is ready, Caret works out what changed since the last sync and your agent makes the app match, in whatever framework you ship. It snapshots first, so undo always works, and it never merges the two for you.

Use Caret with your own agent and harness.

Designing happens in Caret, signed in with the AI coding plan you already pay for. Pushing those designs into your app can happen here too, or you can hand the sync to the agent in your terminal over MCP.

Questions we get asked.

Supported platforms.

Free forever, runs on your machine, no account.

Also: Windows on Arm · Windows portable · .deb · .rpm