An eight-stop tour through how Claude turns an ambiguous request into a finished, polished site. The page you’re reading is the worked example — each stop ahead is a step in the workflow that built it. You click through it; it never scrolls past you.
← → arrow keys · the dots above · or the buttons below move between stops
Most guides about Claude Code tell you how it works — lists of features, enumerated flags, sketched flowcharts. This one is different. It shows you, by walking through the build of itself.
Every stop you’ll read maps to a real moment in this site’s construction — a real decision, a real tradeoff, a real piece of code. Nothing here is hypothetical. The thing you’re using is the thing being explained.
If you’ve ever wondered what it actually feels like to design and ship software with Claude as a collaborator, this is the closest you can get without opening a terminal yourself.
Every stop is structured as a real moment in the build — what was being thought about, what was decided, why a path was chosen and another abandoned. The site is both the lesson and the lesson plan. The argument and the evidence. Pull on any thread and you’ll find the work underneath it.
The medium is the message — the site you’re using is the proof that the workflow works.
Begin where Claude begins: not with code, but with a way of thinking.
Before the first character of code, Claude is doing the unglamorous work — reading context, asking the right questions, mapping the shape of the problem. Half the win comes from how you start.
Good code starts with good understanding. The model that prepares well writes less code, fixes less code, and ships with more confidence. A few minutes spent reading the surrounding files, naming the real constraint, and sketching the shape of the change pays back many times over — fewer wrong turns, fewer rewrites, fewer surprises waiting in the next pull request. Thinking isn’t a delay before the work. It is the work.
Look at the codebase, the conventions, the user’s recent messages. Don’t propose anything until you’ve read enough to know what you’re walking into.
What someone types is rarely the whole picture. A clarifying question costs seconds; an unwanted feature costs hours.
Break the problem into pieces small enough that each one has an obvious next move. Sequence them.
A series of tiny edits you can undo beats one giant change you have to defend. Mistakes get cheaper.
Read for known files. Grep for symbols. Subagents for parallel research. Plan mode for non-trivial scopes. Match the move to the task.
There is a strong gravity toward typing. A blinking cursor feels like progress; a quiet moment of reading does not. But the model that pauses to read a file, ask one good question, or sketch a plan is doing the most valuable work in the session — not the least. The pause is where the wrong solutions get filtered out before they cost anything.
The cheapest moment to change your mind is before you’ve written anything.
The literal request and the intended one are rarely the same. The first job is to find the gap and close it before it costs anything.
Most requests are compressed. The user has a fuller picture in their head than the words on the screen carry. Take the literal interpretation and you’ll often produce something technically correct and entirely useless — a working answer to the wrong question. The real work is decompression: expanding the sentence back out into the picture it came from. That picture is where the build actually lives.
The opening request for this site was four words.
> we are going to make a now website
In most contexts, “now website” points to a /now page — the small personal status pages popularized by nownownow.com. A reasonable guess. But it was a guess, and acting on it would have built the wrong thing.
So the response wasn’t code — it was a clarifying question. Standalone or part of an existing site? Plain or designed? A content draft, or a starter you’d build on? The reply made clear the request had nothing to do with a /now page at all.
> it is goimg to be a informational website on how to use > claude code to dezin and make thing s like the wedsite. > ... ues agents for each page ... color be white orenge and black.
Two short sentences. The literal first message would have produced a personal status page. The actual ask was a multi-page interactive guide — the very thing you’re reading.
One question saved hours.
Not every question helps. The good ones share a shape.
Pretending to understand is a tax the user pays later — in rewrites, in walked-back features, in the slow erosion of trust that comes from a build that keeps missing.
Asking is faster than guessing, even though it feels slower in the moment. The pause before the work is the cheapest part of the work.
A clarifying question costs seconds. A misread request costs the whole build.
Once the request is clear, the work splits into pieces. A good plan names the pieces, sequences them, and finds what can happen at the same time.
Planning isn’t about producing a polished document. It’s about getting alignment — between you and the model, between the work and the intent. With Claude Code, the plan is usually a short conversational proposal: here’s what I’ll do, here’s the order, here’s what I’d skip — sound right? That exchange is the artifact. Nothing more is needed.
Break the work into pieces small enough that each one has a single, obvious next action. If a piece is fuzzy, it’s not small enough yet.
Find the dependencies. What has to exist before the next piece can start? Foundations first; finish work last.
Spot the pieces that don’t depend on each other. Those can be done at the same time, by separate agents, with no coordination cost.
After the request became clear, the plan was a short proposal — eight pages, built by eight agents in parallel, but only after a shared design system was in place.
Pages (8 total): index.html — landing / intro thinking.html — how Claude approaches a problem 01-understand — understanding the request 02-plan — planning the approach 03-design — design decisions 04-build — writing the code 05-refine — iterating & polishing 06-finished — the finished product Build approach: 1. Write shared styles.css + transitions.js first 2. Spawn ~8 agents in parallel — one per page 3. Assemble & spot-check at the end
The user said “go ahead.” That confirmation is the plan being approved.
The most important planning question is rarely what should we build first? It’s what has to exist for everything else to be consistent? For this site, that was the shared CSS. Without it, eight parallel agents would have produced eight different-looking pages — eight micro-aesthetics colliding at the seams. With it, they could all move at once and still arrive at one place.
The foundation goes first. Everything else can then go fast.
Parallelism is cheap once the contract is shared.
Three colors. Two typefaces. One layout rhythm. The fewer the choices, the more obvious each one becomes.
A blank canvas is paralyzing. A canvas with three colors and two typefaces is a problem you can actually solve. Design is not about generating options. It is about closing them. Every constraint you accept up front is a hundred decisions you will never have to revisit later — no debate over a fourth color at midnight, no second-guessing a third typeface on page nine.
The work shifts from invention to application. You stop asking “what could this be?” and start asking “given what we agreed, what does this want to be?” That is a much smaller, much more answerable question.
White as the page, black as the ink, orange as the accent. If you need a fourth, you don’t — you need to use one of the three differently.
Space Grotesk for display, Inter for body, JetBrains Mono for code. Each typeface has one job. Mixing roles produces noise.
Black hero slabs alternate with white reading sections. The reader’s eye learns the pattern after the second stop.
A blur-and-fade for navigation, a quiet rise for reveals. Motion exists to confirm what just happened — never to perform.
The user gave the palette: white, orange, black. That’s a constraint with a payoff.
Those three colors fixed dozens of downstream decisions on the spot. What color is a card hover? Orange. What color is a code block? Black. What color is the page? White. What color is a link? Orange, until it’s read, then still orange. No deliberation, no swatch boards, no afternoons lost to “is this teal a little too cool?” The answer was already on the wall.
:root {
--black: #0A0A0A;
--white: #FAFAF7;
--orange: #FF6B35;
--orange-deep: #E04A12;
--orange-soft: #FFE9DF;
}
Five tokens cover the whole site. Five.
Every animation on this site is doing one of exactly two jobs. The first is confirming a navigation — a transition that ties what you left to what you arrived at, so the jump feels like a step instead of a cut. The second is revealing the next chunk of reading — a quiet rise as a stop arrives, so the page meets you at your pace. Nothing loops. Nothing decorates. Nothing bounces for the sake of bouncing.
If a reader notices the animation, the animation is wrong.
The slow way is sequential — one piece at a time, in order. The fast way is to do the foundation alone, then everything else at once. The trick is knowing which is which.
Anything that everything else depends on has to exist — and be stable — before parallel work starts. For this site, the foundation was two files: styles.css and transitions.js. Eight pages were going to be built in parallel by eight separate agents. If those agents had also been writing the CSS, they’d have written eight different design systems — eight type scales, eight color palettes, eight ideas of what a card looks like. The foundation gets written once, by one mind, before anyone else gets to touch the project.
A subagent is a fresh thread with its own context window. Spin up eight at once and the work that would have taken an hour takes minutes — but only if you set them up to succeed.
Subagents work best on tasks that don’t need each other’s output. Eight pages, eight prompts, no cross-talk.
Each agent gets only what it needs. The main thread’s context stays clean for assembly and review.
If every agent inherits the same design contract in its prompt, the eight outputs feel like one site, not eight.
Once the shared CSS and JS were written, eight Agent calls went out in a single message — one per page. Each agent received the same design contract and the content brief for its specific page.
// All in one message, dispatched in parallel:
Agent({ description: "Write index.html", prompt: "[brief + content for home]" })
Agent({ description: "Write thinking.html", prompt: "[brief + content for mindset]" })
Agent({ description: "Write 01-understand", prompt: "[brief + content for step 01]" })
Agent({ description: "Write 02-plan", prompt: "[brief + content for step 02]" })
Agent({ description: "Write 03-design", prompt: "[brief + content for step 03]" })
Agent({ description: "Write 04-build", prompt: "[brief + content for step 04]" })
Agent({ description: "Write 05-refine", prompt: "[brief + content for step 05]" })
Agent({ description: "Write 06-finished", prompt: "[brief + content for step 06]" })
Eight outputs in roughly the time of one.
Each agent’s prompt didn’t say “make a page about X.” It spelled out the exact CSS classes available, the required HTML skeleton, the journey nav (with the right item marked current), the prev/next links, and the content for that specific page. The more precise the contract, the more consistent the result. Vague briefs produce eight different sites; tight briefs produce one.
A subagent inherits no context. The brief is everything it knows.
The first draft of anything is a guess that came out of the keyboard. Refining is the work of asking, of every line: does this need to be here?
Subagents are confident. Their summaries describe what they meant to do — not necessarily what they did. The moment the parallel work returns, the main thread’s job is to actually look. Open the pages. Click the links. Check that the journey nav is consistent across files. Verify the prev/next chain end to end. Spot a card that didn’t get the reveal class and add it. The diff between intent and reality is small, but it is never zero.
Open every output. Click every link. Compare what was promised to what landed. Fixes here are cheap.
Cut anything that doesn’t earn its place. A removed line is faster than a refactored one.
Hover states, focus rings, motion timing, the small things that make a page feel cared for. Done last, never first.
When the eight page agents returned, the assembly job was a quick read of every file.
is-current?reveal class on its content blocks?Most of the work was small. Most refinement is.
There is always a paragraph you are proud of, a flourish you want to keep, a card that took an afternoon. If it doesn’t earn its place on the page, it has to go. The page is better when nothing in it is showing off — when every part is just doing its job, quietly, in service of the reader.
If you can’t justify a line in one short sentence, the line shouldn’t be there.
Every stop in this deck is a step in the workflow that built it. The artifact and the case study are the same object. That was the whole point.
Eight pages of source content, built in roughly the time of one. Here’s the recap.
This site happens to be eight pages, but the same five moves — clarify, plan, design the foundation, parallelize the rest, refine — work just as well for a single function or a whole product. The shape of the work doesn’t change with the size of the project.
What changes is how many of each move you make. A one-line fix might need thirty seconds of clarifying and no parallelization at all. A larger system might need a week of planning and a dozen subagents. The order is the same. The discipline is the same.
The model that pauses, plans, and asks one question at the start ships more than the model that types right away.
Open it on a project of your own. Start with something small. Notice when the workflow slows down — and notice that the slow part is usually where the value is.