We just watched Claude Code generate a full landing page, dark mode, light mode, correct copy, correct fonts, correct numbers, from a single prompt. Then we watched the same request go to a blank design chat and come back with default fonts, a generic color palette and none of the actual business details right. Same underlying model. Wildly different output. The difference was not the prompt. It was everything sitting behind it.
What the Claude Code design skill actually does
Anthropic recently added a design skill to Claude Code that brings an editable artboard workflow, the kind Claude Design already offered, directly into a coding session. It runs on top of Claude Code artifacts, the live shareable pages Claude Code can now publish straight from a terminal or IDE session. Instead of describing a page and getting flat code back, you get an editable draft: accent colors, spacing, font scale and copy can all be adjusted from a visual panel, closer to Figma than to a chat window.
The workflow we have been testing looks like this: prompt Claude Code with a build request, get back an artboard, edit the details that need editing, leave comments directly on the canvas for anything that needs a bigger change, then ask the same session to write the production code and ship it. Because artifacts are shareable pages, a client or a partner can review the draft with a link instead of a screen share. And because the session is still Claude Code, not a separate design tool, the same chat can push the finished build live once it is approved.
Why one prompt built an on-brand page and the other did not
This is the part operators should sit with. A general design chat starts from zero. It does not know your brand, your offer or your numbers, so it asks clarifying questions or guesses, and the guess is generic: default fonts, default color palette, made-up details. Claude Code starts from your accumulated project context: a CLAUDE.md file, brand notes, prior sessions, and any skills you have built for repeatable procedures. That context is what let one prompt land close to production-ready.
Anthropic's own skills documentation makes the mechanism explicit: a skill's instructions load only when they are actually used. That means a library of brand guidelines, copy rules and design systems can sit dormant and cheap until a session calls for them, instead of bloating every single prompt. That is a structural difference from a chat that starts fresh every time, and it is the reason better prompting is the wrong lesson to take from this. The lesson is memory infrastructure.
Memory is the build input, not the model
We keep seeing the same pattern across every client build we run, not just design. The system that performs is the one with real memory of the business behind it: brand voice, offer details, past decisions, standard operating procedures, client history. The system that underwhelms is the one running on a bare prompt against a general model, no matter how capable that model is. Model quality closed most of the gap between vendors a while back. Context is the gap that is left.
In practice, that means treating three things as build infrastructure rather than one-off chat history:
- A written source of truth for brand: fonts, colors, tone, approved claims, product names, so any AI session can pull from it instead of guessing.
- Reusable procedures captured as skills or documented steps, so the same quality of output does not depend on one person remembering to type the right instructions.
- A standing habit of feeding real business context into a session before asking for output, not after correcting a generic first draft.
Anthropic's own guidance on writing skills is a reasonable starting point if your team has not built one of these yet.
A short comparison of the two workflows
| Prompt alone, no memory | Prompt plus business memory |
|---|---|
| Generic fonts and colors by default | Brand fonts and accent colors applied automatically |
| Asks clarifying questions or invents details | Pulls real product and offer details from context |
| Needs a second tool to hand off for build and deploy | Same session edits, builds and ships the page |
| Rework happens after the first draft | Rework happens inside the first draft, before it ships |
What this changes for a site build this quarter
If you run a 10 to 50 person company and you have a landing page, product page or campaign page on the list, the practical move is not chasing the newest design tool. It is building the memory layer first, then letting a design skill or any AI build tool draw from it. A page generated against a real brand file and real offer details needs a fraction of the correction a page generated cold needs, and that gap shows up directly in how many rounds of feedback a build takes before it ships.
We build this memory layer for clients as part of our Second Brain product, alongside the automation systems that keep it current as the business changes. When we scope a build through our AI Concierge assessment, the first question is never which model or which tool to use. It is what context already exists, what is missing, and what needs to be written down once so every future AI session, design, copy, or ops, can draw from the same source instead of starting cold each time.
Where the deploy step fits
The workflow we tested also folds hosting into the same session: once a draft is approved, the same chat can push it to Vercel without switching tools. That is a small detail but it matters for a 10 to 50 person team, because it removes a handoff. Fewer handoffs mean fewer places a project stalls waiting on someone else's calendar. It is the same principle behind everything else we build: an agent that works a task end to end 24/7 beats a human-in-the-loop chain with five approval steps, even when each individual step is fast.
The same design skill can produce email templates, mobile mockups and 3D product renders. The same memory principle applies to all of them: quality tracks how much real business context the session can pull from, not which model card ships that week. Operators who write down their brand system, offer details and standard procedures once will get compounding value out of every AI tool that shows up after this one. Operators who do not will keep re-explaining their business to a new chat window every time.
What we are doing about it
Inside luup we treat this the same way we treat any new build surface: we do not chase the tool, we check whether a client's memory layer is ready for it. For most of the 10 to 50 person companies we work with, a first system can be live in days to weeks once the context exists. That includes a website rebuild, an AI Operations Agent or an AI Chief of Staff, and clients keep full ownership of the code and files it produces.
If your team is losing the 10 or more hours a week that a typical operator loses to manual admin and rebuilding context by hand, that is the leak worth closing before the next design tool release. You can see where those hours are going with our free revenue leak heatmap, read how other operators structured their build in our case studies, or start with the €999 assessment, credited in full to the build, at the assessment page. We cover build patterns like this one regularly on the blog.
The takeaway
A design skill that turns one prompt into a near-finished, on-brand page is a genuinely useful tool. But the tool is not what made that page good. The memory sitting behind the prompt did. That is the shift worth building for this quarter, regardless of which vendor ships the next feature.