Edit a Framer site with cursor or claude code

You can't point Cursor, Claude Code or Copilot at a Framer project, because Framer stores it in its own editor and has no code export. What you can do is convert the published site into a TypeScript project with Deframer, open that folder in your AI coding tool, and edit it as code. A converted site is plain React and TypeScript with a README that maps each URL to its file, which makes it a good fit: the tool can read it, change it, and you can check the result in a running dev server and a Git diff.

This post covers why that works, a step-by-step workflow, prompts that give good results, and the guardrails that stop an assistant from making a mess.

Why a converted site suits AI coding tools

AI coding assistants do best on code that is conventional, typed and split into small files. A converted Framer site has those properties:

• Standard frameworks. The default output is a Next.js 16 App Router project with React 19. You can also choose TanStack Start, Astro, React Router or Vite. The tools have seen all of these.
• TypeScript everywhere. Every file is .ts or .tsx. Types give an assistant, and the compiler, something to check its changes against.
• One page, one place. Routes live in src/app (or the target's equivalent), page content in src/views, components with a CSS module each in src/components, color and text styles in src/styles, and CMS collections as JSON in src/cms. When you say "change the pricing section", there's a short path to the right file. What you get in a converted Next.js project tours each folder.
• A README with a map. The generated README lists every URL with the file that renders it and says where to edit what. Give it to the assistant as context.
• No Framer runtime to puzzle over. A small helper kit in src/lib/deframer replaces it, and the rest is ordinary code.

One caveat: converted output is generated code. It's tidy, but it isn't hand-written, and a few files, such as the helper kit, are better left alone. We come back to this in the guardrails.

What you need first

1. The site as a project. Paste your published address into Deframer. Converting is free. To download, add the one-line verification tag in Framer's custom code settings and publish; a verified download costs 1 credit (10 without verification). See pricing and verifying Framer site ownership. Deframer is for your own site or one whose owner has given permission.
2. Node.js and an editor. Next.js 16 needs Node.js 20.9 or later; the TanStack Start, Astro and React Router targets need 22.18 or later (React Router 22.22). Use Cursor, VS Code with Copilot, or a terminal with Claude Code.
3. Git. Not optional for this workflow. It's what makes AI edits safe.

The workflow

1. Get a clean baseline

unzip my-site.zip
cd my-site
npm install
npm run build
git init
git add .
git commit -m "Initial conversion from Deframer"

Commit before the assistant touches anything. If a session goes badly, git diff and git restore bring you back. Maintaining a converted Framer site with Git explains why the untouched first commit matters.

2. Start the dev server and keep it open

npm run dev

Keep the site open in a browser next to the editor. The dev server reloads on save, so you see each change within seconds. That's the loop that makes AI edits fast and checkable: ask, look, accept or revert.

3. Give the tool context, once

Add a short instruction file at the project root: AGENTS.md for tools that read it, CLAUDE.md for Claude Code, or .cursor/rules for Cursor. It's a new file you create; the conversion doesn't include one. Something like:

# Notes for AI tools

- This is a converted Framer site. Read README.md for the URL-to-file map.
- Pages: src/views. Routes: src/app (metadata only). Components: src/components, each with a CSS module.
- Colors and fonts are tokens in src/styles. Use them; don't hard-code hex values.
- CMS content is JSON in src/cms. Don't hand-edit generated schemas.
- Don't edit src/lib/deframer (the runtime kit).
- Run `npm run build` after changes and fix type errors before finishing.
- Keep edits small, and don't reformat files you aren't changing.

Adapt the paths to the target you chose; the README in your own download lists them.

4. Work in small, named tasks on a branch

git switch -c copy-and-pricing-tweaks

One task per branch, or at least per commit. A request like "improve the whole site" produces a diff nobody can review. A request like "change the hero headline" produces one you can read in a minute.

5. Review the diff, then build

Read the diff before you accept it. Then run npm run build and look at the page at phone and desktop widths. Commit with a message that says what changed, then merge when you're happy.

Example prompts that work well

Specific prompts with a file, a scope and an acceptance check do best.

Copy and content

• "Change the headline on the home page in src/views/home.tsx to 'Ship your site faster'. Don't change any styles."
• "Add a fourth item to the FAQ on the pricing page, copying the structure of the existing items."

Styling

• "In src/components, find the primary button and make its corner radius 12px, using the existing CSS module. Show me which files you changed."
• "Replace the hard-coded gray in footer.module.css with the matching token from src/styles."

New pages and components

• "Add a /contact page that mirrors the structure of /about: same layout template, new copy, and metadata for title and description."
• "Extract the repeated testimonial card in the home view into one component in src/components, and use it in both places."

Metadata and SEO

• "List every page's title and description from the route files, in a table, and flag any over 60 and 160 characters."

Fixes

• "The mobile menu overlaps the logo below 400px. Find the cause in the header component's CSS module and propose the smallest fix before editing."

Ask for a plan first on anything non-trivial. "Describe what you'd change and which files, then wait" costs a minute and saves unwanted edits.

Guardrails

AI tools are fast, and they're confident when they're wrong. A few habits keep the site safe.

• Branch for every task. main should always build. Merge only after review.
• Read every diff. Look for files you didn't ask to change, deleted code, renamed props and "while I was there" cleanups. Reject those.
• Build before you merge. npm run build catches broken imports and, in most setups, type errors that look fine on screen. If your target has a type-check script, run that as well.
• Test the pages that matter. Open the home page, one CMS page, a form and the navigation on mobile. Forms especially: if a change touches one, submit it and confirm your webhook or form service gets the data (forms after leaving Framer).
• Protect the generated parts. Leave src/lib/deframer and the CMS schemas alone unless you're sure. Put your own code in new files, rather than rewriting generated ones, so it survives re-conversion.
• Don't paste secrets into prompts. Keep webhook URLs and API keys in .env.local, which the project's .gitignore excludes.
• Don't let it add dependencies freely. A new package should be a decision you make, not a side effect.
• Keep animations checked by eye. Assistants can't see motion. If a change touches animation, look at it, and see keeping Framer animations in Next.js with motion.

If you keep designing in Framer too

Many people don't leave Framer completely: a designer still edits there, and a developer improves the code. That works, but the two copies diverge. Your options:

• Treat the code as the source of truth after conversion and stop editing in Framer. Simple, and it's what most people who convert end up doing.
• Keep Framer as the design source and convert again after each republish, keeping the conversion on its own branch and merging it into the one the AI tool edits. Merges are easier when your changes sit in new files and small edits rather than rewrites. The method is in the Git maintenance post.

Re-converting is free; downloading a republished site uses a credit.

When AI editing isn't the right tool

• Big visual changes. If you're redesigning, a designer working visually is faster than describing layouts in words.
• Pixel matching. Assistants approximate. Compare against the design and fix by hand.
• Content-only changes on a CMS-driven site: edit the collection, not the code. For editors who aren't developers, adding a headless CMS to a converted site is a better route.

Cost and ownership

The conversion costs 1 credit per verified download ($10 for one, $25 for five, $100 for thirty, credits never expire), and the $397 lifetime deal makes verified downloads free. What the AI tools cost is between you and their vendors. Once you've downloaded the code, it's yours: no Framer runtime, no lock-in to Deframer.

If you build sites for clients, the affiliates program pays 50% of each sale you refer.

Deframer is independent of Framer, Cursor, Anthropic and GitHub.