DEV Community: Alex

Claude Design gives you a prototype. Then what?

Alex — Mon, 20 Apr 2026 13:32:59 +0000

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.

I made Claude Code slower. On purpose. Here's why.

Alex — Thu, 09 Apr 2026 14:10:09 +0000

You're 40 minutes into a Claude Code session. You've lost track of what you decided.

Claude is re-reading files it already read. You're not sure if you're building the right thing anymore, and you're not sure when you stopped being sure.

This is not a Claude problem. It's a structure problem. That's why I built FRAME.

What FRAME is

FRAME is a set of Markdown files that give Claude Code a role to play and a gate to stop at. Nothing installs beyond copying a few files. No config, no runtime, no dependencies. You run /frame load sw-development and Claude Code knows it's a Requirements Engineer now, and that it doesn't move until you confirm what you're building.

The core mechanic: a cartridge defines the phases, roles, and gates for a particular kind of work. The engine reads the cartridge and runs the session accordingly. You keep control at every gate — nothing advances without your y.

That's it. The rest is Markdown.

Two runs, same task

I wanted to test this honestly, so I ran the same bug fix twice — once with plain Claude Code, once with FRAME's sw-development cartridge. Same prompt, same codebase, same starting branch.

The bug: _get_daily_limit() crashes when NOTEBOOKLM_DAILY_LIMIT is set to a non-numeric value or zero. Fix it and add tests.

Plain Claude Code read the function, wrote the fix, wrote the tests, committed. About a minute. No questions asked. The fix was correct.

FRAME started by asking questions. Branch name? Hard constraints? Acceptance criteria beyond what was stated? Anything explicitly out of scope? It produced a SHAPE block before touching a single file:

Goal       : Fix _get_daily_limit() crash - non-numeric or zero env var
Stack      : Python 3.9+, pytest
Branch     : fix/frame-daily-limit-validation
Constraints: none
Acceptance : - Non-numeric → returns 50, no exception
             - Zero → returns 50, no exception
             - Negative → returns 50, no exception
             - Valid numeric → still works correctly
             - At least one test per bad-input case
Out of scope: all other functions, no refactoring, no interface changes

You confirm this, or you push back. Only then does it write code.

Some minutes later, the fix landed. Same correctness as plain CC. But then the QA Engineer ran a pass — mapping every acceptance criterion to a test, checking for gaps. It flagged one: whitespace-only strings (" ") aren't covered. A fourth test, not in the original brief.

Plain CC found its edge cases by instinct. FRAME found them by process.

The honest framing

FRAME didn't produce better code. It produced a documented contract for what the code was supposed to do — agreed before anything was written, verified after.

For a contained bug fix where you know exactly what you want, plain Claude Code is hard to beat. One minute versus ten is a real difference.

FRAME earns its keep when "what does done look like?" isn't obvious before you start. When the session is a decision, not just a task. When you're about to build something that depends on choices you haven't made yet, and you don't want to discover mid-BUILD that you've been building the wrong thing.

The ten minutes isn't overhead. It's the work of agreeing on what you're building before you build it. For the right task, that's the most valuable ten minutes in the session.

That right task looks like: a feature with ambiguous requirements. A codebase you haven't touched in six months. An audit where you need to explain every finding to a stakeholder. A project plan that has to survive a conversation with someone who wasn't in the room when it was made.

In those sessions, the documentation FRAME produces isn't a side effect — it's the point. The SHAPE archive records what was agreed before code was written. The phase archives record what was decided at every gate. The final output is something you can hand to someone who wasn't there and they can reconstruct exactly what happened and why. Plain Claude Code produces an output. FRAME produces an output and a record.

How it works

A session has five phases: SHAPE, BREAKDOWN, DESIGN, BUILD, CHECK.

SHAPE is where the Requirements Engineer extracts the goal, stack, constraints, and scope. No code is touched. The output is a PROJECT.md you confirm before anything else happens.

BREAKDOWN is where the Orchestrator turns the goal into work units — small enough to complete in one context window, sequenced by dependency. The first time I saw the unit list appear I understood why FRAME works: a project that felt overwhelming at the goal level becomes a list of five things, in order, with clear scope. The Tur-Tur effect — something that looks impossibly large from a distance resolves into ordinary steps up close.

DESIGN is where the Architect turns the unit list into a plan — interfaces, dependencies, sequencing decisions. Nothing is built yet. The point is to make implementation choices explicit before a Developer touches a file.

BUILD executes one unit at a time. Gates between units let you /clear context without losing state — FRAME writes everything to file before it stops.

CHECK runs a Code Reviewer and QA Engineer pass. This is where the acceptance criteria table appears, mapped to actual test coverage. Gaps surface here, not in production.

The cartridge is just Markdown. You can read every instruction Claude Code is following. You can edit them. You can build your own in an hour using the cartridge-creator cartridge.

What makes it different from SPARC, claude-flow and others alike

Those tools are powerful. If you want multi-agent orchestration, parallel execution, XML-structured plans, and a framework with a full ecosystem — use them. They're built for that.

FRAME is deliberately smaller. No multi-agent complexity. No tooling overhead. No XML. The entire engine is one Markdown file. The design principle is: if it needs an installer to be useful, it's already too complicated.

If you want a framework, use SPARC or claude-flow. If you want structure without infrastructure, this is for you.

Get it

git clone https://github.com/SeriousByDesign/frame.git
cd frame
bash install.sh

Then, in any Claude Code session:

/frame load sw-development

FRAME is domain-agnostic — the engine stays the same, the cartridge defines the kind of work. Available initially: sw-development, code-audit, blog-writing, linkedin-profile, project-planner, cartridge-creator. Each one is a validated workflow you can use as-is or modify. Build your own with cartridge-creator.

v0.3.0 added four more: codebase-analysis (structured documentation reports from an existing codebase), findings-to-tasks (turns audit findings into actionable tasks), skill-creation (designs and validates new Claude Code skills), and document-and-commit (documents and commits code changes made outside of FRAME).

Where it is

This is v0.3.0. Validated across real sessions — software development, code audit, blog writing, LinkedIn profile creation, cartridge authorship, project planning. All core design decisions are closed.

It's not done. I'm looking for people who like to run it on real work, file issues when it breaks, and tell me where the friction is. If that's you, the repo is at github.com/SeriousByDesign/frame. Just want to give it a go? You're welcome as well. Everyone is.

Break it. That's the point of v0.3.0.