Anthropic launched Claude Design on Friday. By end of Saturday I had a working FRAME cartridge that wires it into a structured development workflow. Not because I planned to – but because the architecture made it obvious.
That’s the thing I wanted to test: whether FRAME’s engine/cartridge split actually holds when something new drops. New tool, new domain, new workflow. Does the engine stretch to cover it, or do you end up patching around it?
Here’s what happened.
If you haven’t heard of FRAME (which is likely): it’s a prompt-native workflow engine for Claude Code. Instead of a freeform session, you load a cartridge – a set of Markdown files that defines phases, roles, and checkpoints for a specific kind of work. SHAPE gathers requirements. BREAKDOWN decomposes scope. DESIGN decides the approach. BUILD implements one unit at a time. CHECK reviews the output. A fixed engine handles state, commits, and resume across /clear. Cartridges define the domain.
The architecture is deliberately split: the engine never changes, cartridges define what happens in between. That split is what this post is actually about.
The gap Claude Design creates
Claude Design is impressive. You describe what you want, it asks a few focused questions about aesthetic direction and layout, and it produces a working interactive prototype — not a static mockup, an actual React app with localStorage state, seed data, and live interactions. In a single session.
A daily habit tracker web app. Three screens:
- Dashboard – shows today’s habits as a list with checkboxes, a streak count per habit, and a weekly completion ring per habit. Header shows today’s date and an overall completion percentage for the day.
- Add/Edit habit – form to create or edit a habit. Fields: name, frequency (daily / weekdays / custom days), colour tag, optional reminder time. Save and cancel actions.
- History view – a monthly calendar grid where each day cell shows a coloured dot per habit indicating completion. Tapping a day shows a popover with that day’s detail.
- Target: web app, light mode, clean and minimal aesthetic.
- No authentication needed. Assume a single user.
The problem is what comes next. The “Handoff to Claude Code” button gives you a command that says: fetch this design file, read its readme, and implement the relevant aspects of the design. Claude Code takes that literally. It fetches the bundle, reads the prototype HTML, and starts implementing.
Which sounds fine – until you think about what it doesn’t know. It doesn’t know what you originally asked for. It doesn’t know what Claude Design added beyond scope. It doesn’t know what production stack you want, because Claude Design deliberately deferred that decision. It doesn’t know which of the prototype’s design choices were intentional constraints and which were defaults.
FRAME knows all of those things, because it asks.
Designing the cartridge
The phase sequence came together quickly once I looked at how the handoff actually works.
The raw sw-development cartridge goes: SHAPE → BREAKDOWN → DESIGN → BUILD → CHECK. For a Claude Design workflow, DESIGN is redundant – Claude Design already made those decisions. What you need instead is a review step between the handoff and decomposition: something that checks what came back against what you agreed to build.
I called it DESIGN-REVIEW.
SHAPE → [Claude Design - external] → DESIGN-REVIEW → BREAKDOWN → BUILD → CHECK
SHAPE gets two extra responsibilities: a question about existing design systems and brand assets, and a second output – design_brief.md, a clean brief formatted for Claude Design, not for FRAME. No SESSION headers, no gate blocks. Just: what to build, which screens, what constraints.
The gate at the end of SHAPE tells you to drop brand assets into design-assets/ before attaching the codebase in Claude Design – it’ll pick them up automatically. Then it tells you exactly what to do when you come back: paste the handoff command, don’t implement yet.
DESIGN-REVIEW intercepts the handoff command. It extracts the bundle URL, fetches it, reads the README and the prototype HTML – then does the work the raw handoff skips:
– Which screens did Claude Design actually cover?
– What did it add that wasn’t in scope?
– What stack decisions need confirming?
– What production gaps does BUILD need to address that the prototype didn’t?
The output is a structured review that BREAKDOWN and BUILD read instead of a DESIGN document. Everything from BREAKDOWN onward is inherited from the sw-development cartridge unchanged.
The test run
I used the cartridge to build a habit tracker – the same prompt I’d used earlier to test Claude Design itself, so I could compare prototype to implementation directly.
SHAPE ran cleanly. One question at a time, screens locked, out-of-scope list explicit. Then I took design_brief.md to Claude Design by attaching the project folder via Import → Link code folder. Claude Design reads everything in the linked folder, picking up the brief and any assets in design-assets/ automatically. It asked a few questions about aesthetic direction (should have kept the white background) and produced this:
Then the handoff. The command came back as a URL instruction – not a zip, not a set of files. Just a hosted bundle with a README telling Claude Code to fetch, read, and implement. I pasted it unchanged into the Claude Code session.
DESIGN-REVIEW didn’t implement. It fetched the bundle, read it, then surfaced the scope additions: drag-to-reorder (Claude Design added it; HTML5 drag works desktop-only), a history stats bar (not in the original brief but already designed), and the Tweaks panel (explicitly out of scope). It asked about each one. I kept the stats bar, scoped drag-to-reorder to desktop-only, descoped Tweaks.
BREAKDOWN split the confirmed scope into five units. BUILD worked through them with the prototype HTML and CSS as visual reference.
This is what the cartridge produced, single run, no tweaks, running on Sonnet 4.6 – not the Opus 4.7 model that made the original:
The cream background, terracotta accent, strikethrough on completed habits, the “Not today” section, the weekly rings. Not identical – the flame emoji became a droplet, the date header got a touch of italic weight – but close enough that you’d use it.
After CHECK passed, I ran the deploy cartridge – Vercel target, one command. The habit tracker is live at habit-tracker-nu-blue.vercel.app (demo only – resets on reload, nothing is persisted).
That’s the full loop: brief → prototype → scope review → build → check → deploy. FRAME handled every step except the creative work itself.
What this proves
Two things, I think.
One: the engine/cartridge split works. Claude Design is a new tool with a new workflow. The engine didn’t change. I wrote a cartridge. The phases, gates, state management, and resume mechanic all carry over without modification. That’s the whole point of the architecture.
Two: the separation of concerns between Claude Design and FRAME is genuinely useful, not just structural. Claude Design does the creative work fast – aesthetic decisions, interaction design, visual hierarchy – better than a requirements interview ever could. FRAME does the disciplined work that turns a prototype into a production build: scope review, decomposition, unit-by-unit implementation, test coverage.
Neither replaces the other. Claude Design produces something FRAME would struggle to produce in a DESIGN phase. FRAME produces something Claude Design’s raw handoff doesn’t: a structured build process with a paper trail, scope discipline, and a resume point if you run out of context halfway through.
The Tweaks panel was out of scope. DESIGN-REVIEW caught it. BUILD never saw it.
That’s the workflow working.
FRAME is open source at github.com/SeriousByDesign/frame.
Top comments (0)