Working From an Existing Design
If you’ve already designed your app, Claude can build from that design instead of a written spec. It rebuilds your screens in the Stadium 8 stack, matching their layout, fields, wording and colours.
Designs from Claude Design or Figma, wireframes, and hand-written HTML mockups all work.
How to supply a design
Section titled “How to supply a design”Put the design files in documentation/. There’s no import step and nothing to point Claude at.
If the design came as a .zip, unzip it and put the files in the folder. Loose files, a folder of files, a renamed export or a mix of formats all work the same way. Claude reads the design by understanding it, not by matching a fixed export format, so it isn’t tied to any one design tool.
What happens at Intake
Section titled “What happens at Intake”When you run /start, Claude reads the design files and works out your screens: their layout, fields, wording, validation, colours and fonts. It reads all of this back to you when you review the project setup, so you can confirm it before anything is built.
Claude also tells you what it couldn’t work out from the files. You fill those gaps, so Claude doesn’t have to guess. Open questions that matter for a particular epic come up again on that epic’s stories review page as design choices.
Claude records what it read in generated-docs/design/digest.md. Every later step works from this record, not from the raw design files.
What reads reliably
Section titled “What reads reliably”| File type | How well it reads |
|---|---|
| HTML, wireframes, notes and specs | Reliably. Text-based files are the dependable core. |
| Images, screenshots and PDFs | Less reliably. Rebuilding exact text and layout from a picture is uncertain, so Claude tells you what it’s unsure of. |
| A single bundled export file | Sometimes not at all. Claude says so and asks for the design in a form it can read. |
Nothing is dropped silently. What Claude read, and what it couldn’t, both come up at Intake.
Designs and requirements
Section titled “Designs and requirements”A design gives Claude your screens and their look, not your requirements. If your design comes with a requirements document, Claude uses it. If not, Claude asks a few short questions to fill the gaps, guided by the screens it read.
Updating your design later
Section titled “Updating your design later”Update the files in documentation/ and start a normal piece of work that describes the change. For example: “Rebuild the dashboard and settings screens to match my updated design.” Type /start and choose to build something new.
Claude re-reads the design and builds the change through the usual plan, build, test and merge steps. Only the screens you name change. There’s no special refresh mode.
Your decisions stick
Section titled “Your decisions stick”Claude adds to the design record every time you settle something the files didn’t cover. That might be a colour that wasn’t in the design, where a button should lead, or a change you asked for during testing, such as “move that filter to the right”.
These decisions override your design files. Re-reading the design never quietly puts a screen back the way the files show it.
When Claude re-reads an updated design, it updates the record rather than replacing it, and tells you in plain words what changed, such as “The Export button is now called Download CSV”. If the new design contradicts a decision you made, Claude asks which one to build.
Adding a design to an app you’ve already built
Section titled “Adding a design to an app you’ve already built”You can add a design to an app built without one and rebuild against it. Claude only changes the screens you name, and leaves everything else alone.
If a screen you’re rebuilding should keep its current behaviour rather than match the design, say so, and Claude records that as your decision.