On August 18, 2026, Anthropic product designer Nate Parrott announced an early preview that lets Claude Code's /design handle multiple screen options at once. Developers can type something like /design a few options for {feature} before diving into implementation and receive several screen designs as artboards. The flow is to pick an option, edit it, and then send it straight to implementation. Artboards and production code remain separate, but the work of comparing screens and deciding on a direction now happens right before the code changes.
Anthropic had already built a pathway for visual prototyping through Claude Design, with finished designs handed off to Claude Code. Back in June, the company explained that developers could create, edit, and sync design projects from Claude Code using /design. So the command name itself didn't first appear in August. What's new is a workflow where you generate multiple options while looking at the repository, then continue editing derived from Claude Design and prompt-driven manipulation right inside Claude Code. The generated screens don't become production code themselves—which is exactly why the artboards serve as decision-making material before code changes happen.
Choosing an Artboard Before Requesting Implementation
The /design workflow that Parrott outlined proceeds in this order: generate multiple options, select a preferred artboard, edit it, then implement. The output is created as an Artifact that can be shared as a mockup. Before developers issue a blunt instruction like "build this feature," they can compare the differences among screens born from the same request.
This ordering matters because it inserts a checkpoint for confirming intent before implementation begins. Even when the text of a request stays the same, priorities for information, the placement of input fields, and the relationship between list and detail views can all vary. At least in the announced workflow, you select an artboard before moving to implementation. Even when a team is sharing options, they can discuss which screen to adopt before reviewing changes made after implementation.
According to Parrott, Claude reads the existing codebase and attempts to match the existing UI. This claim of "matching" comes from the product side and doesn't guarantee accuracy or pixel-perfect reproduction. Still, because the options are built with reference to the components and layouts targeted for implementation, the process of translating a generic static image into specifications may be shortened. Exactly how much of the existing naming conventions, components, and spacing decisions can actually be incorporated will depend on how much information each repository contains.
Deepening the /design Feature That Existed Since June
Claude Design launched as an Anthropic Labs research preview on April 17, 2026. At launch, it used Claude Opus 4.7 and was available to individual Pro and Max plan subscribers as well as Team and Enterprise subscribers. Users could generate options from prompts or imported materials, then refine them through conversation, inline comments, and direct editing. The design was then meant to be shared or exported and handed off to Claude Code. From the start, a handoff mechanism existed for using visual options to kick off implementation.
Claude Design itself already has a substantial user base. As of the June update, Anthropic disclosed that more than one million users had used Claude Design in its first week. However, this figure does not represent the number of users of the /design command specifically.
On June 17, Anthropic also added /design-sync, which imports the design system from the Claude Code side into Claude Design. The same update stated that users could create, edit, and sync design projects using /design without leaving the terminal. It also explained that designs could be imported into a codebase, and that live prototypes could be built from code. A round-trip path between visual exploration and implementation already existed at that point.
The August early preview explicitly builds artboard comparison and editing operations into this existing pathway. Parrott explained that Claude Design's editor and prompt-driven operations have been brought into Claude Code. Existing published documentation also describes a pathway involving adding the Claude Design MCP server from Claude Code and running /design-login. The current help pages still retain this setup, and it remains unexplained whether the August preview's built-in integration changes the premise around MCP or login requirements.
Repository Context Determines the Differences Between Screen Options
Claude Design is described as being able to import a design system from sources such as a code repository and work with brand colors, typography, and components. If the imported design information is insufficient, the output inherits those limitations. For practical use of /design, the value hinges on how closely it can align with existing components and layout patterns.
What's being handled here is not image generation. The product designer who created Claude Design has explained that HTML is being used as an interactive visual medium, and has drawn a distinction: Claude Design is meant for early ideation and collaboration, while Claude Code is meant for shipping production software. It's also said not to be well-suited for logo creation. Given this division of roles, it's reasonable to view the artboards produced by /design not as substitutes for a finished product, but as deliverables meant to concretize intent before handing off to implementation.
Whether an existing design system is automatically preserved is a separate matter. When there's a discrepancy between local components and an organization-managed design system, which one takes priority isn't stated in the announcement. Whether accessibility, behavior across different screen widths, and state changes actually get reflected in the implementation also can't be known without verifying the actual output.
Boundaries to Confirm During the Early Preview
The announcement explicitly names Claude Code Desktop and CLI as the surfaces where this is available; to try it, you run /design after claude update. However, the announcement doesn't specify eligible plans, per-account rollout, organizational or regional availability, availability via cloud usage, API provisioning, or the required Claude Code version number. Just because Claude Design's current help documentation describes a beta available from Pro through Enterprise doesn't mean the same conditions necessarily apply to /design.
Data handling, too, will need command-specific clarification. Claude Design's admin-facing documentation states that uploaded assets are stored persistently and that data residency requirements are not currently supported. Project previews run in a sandboxed iframe on a separate Anthropic content domain, accessed via a signed token. But whether Artifacts created through /design are stored for the same duration, and whether the same conditions apply to sharing, access, and billing, cannot be determined from this announcement alone.
When evaluating this early preview, comparing the appearance of generated options alone isn't enough. It's necessary to confirm what actually gets carried over from the selected artboard into implementation, and to what extent the resulting code preserves existing components, responsive behavior, and accessibility. How much design information can be fed back into Claude Code when rework is needed will also affect how usable the implementation truly is. Only once eligibility requirements and Artifact handling conditions are clarified will it be possible to finally judge whether /design is merely a convenient prototyping feature or a gateway that could replace a team's design review process.