Welcome to
the studio.
Three decks taught you the method. This one hands you the workshop keys: the newest tools on the bench, and a set of open challenges to run on your own app. You drive now.
Six things,
from memory.
Same ritual as always: say the answer out loud before you tap. Everything here came from Parts 1 to 3, and everything here gets used in this deck.
Parts 1 to 3 walked in front of you. This one walks beside you. Fewer steps, more provocations, and every exercise runs on your app, not a worked example.
Supervision
levels.
While you were learning the method, Claude Code grew some new driving modes. You already own the right language for them, because architects choose a level of site supervision for every job: resident staff for the risky package, a weekly walk-round for the steady one.
Auto mode
Press Shift+Tab to cycle into it. Claude proceeds through a task without asking permission for every edit, but still refuses the dangerous class on its own: destructive Git commands, production deploys, deleting files it didn’t create. Available on every paid plan.
Periodic inspection: the contractor proceeds, the dangerous decisions still come to you.
The agent view
Run claude agents in the terminal and you get one screen showing every background session and what each one is doing right now. The site-office CCTV wall. (A session you’re typing into doesn’t appear until you send it backstage: press the left-arrow key on an empty prompt, or launch the job from the agent view itself.)
You don’t stand over every trade. You glance at the wall.
Background jobs
Long jobs can run in the background while you do something else. When one finishes, it can open its own draft pull request (a pull request is a proposed batch of changes waiting for your yes; a draft one is explicitly not ready to be folded in): the work parcelled up and waiting at the site office for your review, with a delivery note.
Nothing merges itself. Drafts wait for you.
Auto mode for the well-specified slice you could describe in one sentence. Step-by-step approval for the migration that touches real data. The judgement about which is which is yours, and you’ve been making exactly that call on buildings for years.
Claude
Design.
In April 2026, Anthropic Labs opened claude.ai/design: a studio with chat on one side and a live canvas on the other. You describe a screen, it takes shape as a real working mockup, and you point at things and nudge them. It’s included, in beta, in the Pro and Max plans you already know (young tools wobble sometimes; that’s the tool, not you).
First visit: open claude.ai/design in your browser, sign in with the same account you use for Claude Code, and type into the chat side; the canvas fills on the right. On the ten-station line, this whole chapter lives at Station 5: design before code.
Design flows to build
Press Send to Claude Code (the button’s exact name shifts while the tool is in beta) and the design is handed across for Claude to work from. Not a screenshot to squint at: the actual artefact. If it gives you a download instead, save it and tell Claude where it landed.
Your system flows to design
It works the other way too: /design-sync can pull your app’s real design system into the canvas, so every mockup arrives already wearing your colours and type.
You know this failure from buildings: the beautiful concept sketch the working drawings never quite honour. Here, the sketch and the drawing set share one pipeline. What you approve on the canvas is what the builder receives.
The board is
swappable.
Two good design studios exist right now, and the honest comparison is short. What matters more is the mindset: the playbook treats the design tool as a plug, not a foundation.
Claude Design
Chat-plus-canvas, your real design system pulled in via /design-sync, and one button to send the result into the build. When the design is destined to be built, this is the one.
Google Stitch
Free and quick: ten directions in ten minutes when you don’t yet know what you want. Its handoff into a build is manual, which is fine for exploring and friction for shipping.
One small file in your project, design/PLATFORM.md, records which design tool is active. If a better board arrives next spring, you change the file, not the method. No tool choice you make this year is a marriage.
Never design
thirty screens
one by one.
This is how production teams actually use these tools. One anchor screen. Five or six directional variants of it. Pick one the way you’d pick a concept design. Lock it. Propagate. Every other screen then becomes detailing, not designing.
Vary
Generate 5 or 6 takes on one anchor screen. Same content, different characters: warmer, stricter, denser, softer. The anchor should be the screen that carries the app’s soul.
Lock
Choose like an architect: not “which is prettiest” but “which one could absorb the whole app?” Then lock it. Write it down. The concept stage is over.
Propagate
Every remaining screen inherits the locked direction. Nobody re-opens the concept at detail stage, on buildings or here. That rule is what makes screen number thirty look like screen number one.
Take the Part 3 spec to the canvas.
In Part 3 you ran /spec-writer on a growth feature. If you picked the memory book, this is its moment (if you picked another, use that instead). Open Claude Design and paste:
Sit with the six. Pick the one that could absorb the whole app. Press Send to Claude Code (or save the export and tell Claude where it landed), then in your trip-planner-v2 session:
Never let the hand
that drew it
check it.
By the time a building session asks for your approval, its context is full of its own good intentions. It remembers what it meant to do. A fresh session reads only what’s actually on the page. That one difference is the entire review system, and it’s the instinct behind Station 8 on your line: the review.
One session writes
The builder. Its whiteboard holds the plan, the compromises, and every reason the shortcuts were fine at the time. Ask it “are you sure?” and it will, sincerely, say yes.
A separate session checks
Fresh context, no memory of intentions. It sees the spec, the diff, and nothing else. This is why the 4-check chain spawns separate specialists instead of quizzing the builder.
The designer doesn’t sign off their own building control. Not because designers are careless, but because proximity blinds. Same principle, new material.
Install a rule
that refuses.
Third time you’ve met hooks. First time you install one yourself. The difference between a rule in CLAUDE.md and a hook: prose fades as the context fills up; a hook fires at the moment of the edit, every time, forever.
One rule your app should never break.
Your trip planner has a theme: named colour tokens the whole app draws from. A raw hex colour pasted into a component is how design systems die, one shortcut at a time. Make it impossible:
Watch it refuse.
The hook blocks it, and tells you (and Claude) where the tokens live. Notice what just happened: you didn’t have to remember the rule, spot the violation, or even be in the room. The rule now defends itself.
A hook catches the pattern it was written to catch, nothing more. It’s an accelerator, not a guarantee. The real guarantees live in tests and structure. Think of hooks as the site fence: it stops everyday wandering; it is not what holds the building up.
The long
game.
Everything you build from here will outlive any single session. Three small habits carry a project across weeks, and you already own the machinery for all three. On the line, this is Station 9: the wrap.
NOW.md is the bookmark
End every session with /wrap so it’s current; start every session by reading it. The test: could you leave for a fortnight and re-enter in one minute? If not, the bookmark isn’t doing its job.
Fix now, or file it with a trigger
Mid-build problem? Fix it now, or write it to KNOWN_PITFALLS.md with a named trigger: “address when we next touch the packing list.” Never hold it in your head; never file it without a trigger. Untriggered notes are how things vanish.
Sessions you can see whole
One slice per session. If you can’t describe the change in a single sentence, it’s two sessions. Small changes review well; sprawling ones hide things, from Claude and from you.
Deliberately short. The state/ ritual isn’t new knowledge, it’s old knowledge promoted to habit. The projects that die don’t die of bad code; they die of nobody remembering where things stood.
Put it on
the web.
Everything so far has lived on your Mac. There is a difference between “it works on my laptop” and a URL you can text someone from the pub, and tonight you cross it. This is the stop past the end of the line: the handover.
Cloudflare Pages puts a static site on the public web with two commands: one to create the project (once, ever), one to deploy (every time after). Claude runs both; you keep the URL.
Claude runs both of these for you. The first never runs again; the second is the redeploy, about ten seconds every time after. And if the weather key turns into a fight tonight, it’s fine to ship v1 with the weather strip off: the app is still yours, still live.
The ritual
Open the URL on your phone. Watch your own app arrive over mobile data, nowhere near your Mac. Then send the link to one person you’d actually want using it.
You’ve been holding one all along
These very decks are deployed exactly this way: one wrangler command onto Cloudflare Pages. You’ve spent four evenings reading a deployment.
An app that exists only on your laptop is a model. An app at a URL is a building people can walk into. You have shipped.
Six doors.
No wrong one.
No steps this time, and nothing to complete. Each card is a provocation: take one, give it an evening, see what you learn. There is no order and no grade. This is what practising looks like.
Let go of the wheel
Give auto mode one whole build phase in trip-planner-v2, run as a background job so it shows up in the agent view (send it backstage with the left-arrow key on an empty prompt, or start it from claude agents). Notice what it still asks you about, and what you were glad you watched. You’re calibrating how much supervision this kind of work actually needs.
Break it on purpose
Ask for a change you suspect is a bad idea. Let it land. Sit with the wreckage for a minute, then /rewind your way back to solid ground. (One honest limit: /rewind tracks Claude’s edits, not changes made by terminal commands; that’s what commits are for.) Knowing in your hands that nothing is irreversible changes how bravely you build.
Match this
Design a second screen in Claude Design, as opinionated as you dare, send it over, and hold the line until the built screen matches it exactly. The negotiation between canvas and code is a skill, and this is where you learn your side of it.
Guard something you care about
The hex-colour hook was this deck’s idea. Now write your own. What should never happen in your codebase, the thing that would quietly ruin it? Ask Claude to build the hook that makes it impossible, then try to break it.
The full line, alone
Take your Part 3 feature (the memory book, or whichever you picked) from spec to merged pack through all ten stations, with no deck open. When you get lost, /implementation-guide is the “you are here” map. Doing the route unaccompanied once is what makes it yours.
An evening with your tube widget
The TfL delay widget has been waiting patiently since Part 3. Give it one honest evening: set it up first with Part 3’s new-project steps (a fresh folder plus the starter script), then run /spec-writer, answer the questions properly, and see how far a single session gets. The bet: further than you think.
There is no completion state and no wrong door. Some of these will fizzle; one will probably eat a weekend. Both outcomes are the studio working as intended.
The studio is open.
You have a live app at a real URL, a method that scales past you, and a bench of tools you now know by name. What you build next isn’t in this deck. That’s the point of it.
Part 3 told you to pick something you care about.
Now you have the studio to build it in. The lights stay on. Go.
End of Part 4 · The studio stays open
Stuck on something?
Type it here. It goes straight to Munim.