I have Claude build different playgrounds depending on what I'm designing. A playground is a throwaway page with the real elements on it, the type, the colours, the components, the copy, and controls for each one. When I'm finished, I copy the CSS out, or save the canvas, and Claude builds from that.
I decide on copy before jumping into playgrounds, because layout follows content.
4 bakeloop runs passed only after the tester failed the first fix. One tester found a bug nobody had asked it to look for.
Trust. If Claude builds a fix and then checks its own work, a pass means nothing. It's grading itself. In a loop a separate agent, given the spec and never the code, tests the change on the real app.
Time. Before loops, I was the tester. Run the change, check it, show Claude where it still wasn't working, ask again, repeat. Now the agents run that cycle between themselves, freeing up my time for designing and ideating.
Two places it stops for me. Before the build, I approve both specs. Before anything merges, I read the verdicts and sign off. Everything between those two runs on its own.
In an update, some of the app's stored data got wiped. My recipes came back, because they live in the cloud. But my chats with butter, my baking assistant, were gone. They had no cloud copy.
Does a saved chat survive a reinstall? You can't read that from the code, so I ran it as a loop. The tester saved a chat, cleared everything, and reloaded. It did not come back. A permission rule was missing on the backend. I fixed it, ran the loop again, and this time the chat survived.
Model, prompt and reply length set here, never the client. Only two models allowed, anything pricier refused.
A daily limit per user, a token ceiling per reply. Paying members who use it heavily step down to a faster model for the rest of the day, and butter tells them. Cost capped by design.
A fast model screens every message before the real one answers. Repeat offenders get a strike, then a ban.
Every build teaches me more of the stack, and every bit I learn closes another blind spot. That's how I catch the errors Claude misses on its own. The docs are where that learning lives. Claude writes one the moment a project goes to real code, and keeps it current as the code changes.
When something goes wrong twice, I write it down as a rule Claude reads at the start of every session, so it is never decided again. Nothing is called fixed without proof. Copy is decided before layout.
Seventeen fire on their own at the start of every session. They run from simple time savers, like explain-simply (define every term the first time it appears, so I never have to ask what something means) and always-deploy (merged fixes go live without being asked), to the ones that change how Claude behaves. smart-claude: routing is Claude's job, so it names the right tool or skill at the top of its reply when it makes sense. one-question: before any fix, can it be proved by a test, or only by my eyes? The answer picks the tool, every time.
Named flows for named jobs. I built the loops, each running two or more agents (separate Claudes, each with its own job): bakeloop has one agent build a change, a second test it without ever seeing the code, and a third review it; mobileloop fixes my site at phone width without me watching. Two I adopted from others. retro (Matt Pocock) runs a retrospective on a bad session and ends in a written rule; I was already doing that by hand, so now I don't have to. lavish (Kun Chen) is the mirror of my playgrounds: a playground lets me decide before the build, lavish lets me click and annotate Claude's page after it, so I never have to describe a visual fix in words.
Every decision is written where Claude reads it first. A new session starts where the last one stopped.