Markdown edition

# Carry a reviewed Stitch DESIGN.md into two checked Claude Code components

> Export a real Stitch DESIGN.md, approve its exact revision, import it into Claude Code and check two components against the same design.

By BIGCHANGE.AI Editorial

Published: 2026-10-25T20:58:38.926Z
Updated: 2026-10-25T20:58:38.926Z
Canonical: https://bigchange.ai/blog/stitch-design-md-claude-code-two-components-guide

![Conceptual charcoal illustration of one generic layout on a monitor and two distinct smaller layouts on supported devices beside it.](https://bigchange.ai/api/media/file/stitch-design-reference-two-components-hero-v2.png)
AI-generated conceptual illustration by BIG CHANGE.

Google [Stitch can generate a `DESIGN.md`](https://blog.google/innovation-and-ai/models-and-research/google-labs/stitch-design-md/) from a design project. That gives a Claude Code project a useful starting reference, provided the file really came from the screens you reviewed. This guide follows one owned design into two components and checks the code and rendered result after each change. It is a documentation-based procedure; BIG CHANGE did not run either product or test a reader's project.

## The big change

- **What changed:** Stitch supports exporting design rules as `DESIGN.md`, which can travel with a project into a coding workflow.
- **Why it matters:** One approved file can give two component tasks the same named visual rules, while code and screen reviews catch departures from them.
- **What to watch:** The export, project import and generated components each need verification. A missing export stops this workflow; a generated screen alone does not establish working behavior.

## Before you start

You need access to a Stitch project you control, Claude Code access, permission to edit the target web repository and an owner who can approve its design decisions. Start from a restorable Git revision. Identify the real page task, audience, copy, controls and states, along with the project's framework version, styling method and existing build, test and preview commands. Obtain permission for any logo, font or image you supply. Check the current account limits and usage terms before sending private project material or running either service; this guide assumes no free quota, fixed price or entitlement.

Pick two small components in the same project. Write down their target paths and acceptance criteria before generating code. Keep the existing data and interaction boundaries in view. The goal is a checked implementation of your actual page, so bracketed text below must be replaced with your own facts.

## 1. Review the design in Stitch

Create or open the intended project in [Stitch](https://stitch.withgoogle.com/). Give it the approved assets and a brief that names the real task, content and states. For example:

```prompt
Design [real page and task] for [real audience] using only [owner-approved references]. Include [actual copy and controls] and the relevant loading, empty, error, focus and disabled states. Show desktop and phone layouts. Keep [required navigation and interaction]. Flag unresolved decisions; do not invent brand values or backend behavior.
```

Inspect the actual project screens at both widths. Check copy, hierarchy, missing states, clipping and any unsupported brand choice. Make corrections in Stitch, then record the project and screen identities and the revision you approved for export. A screenshot or HTML file can help comparison later, but it is not the `DESIGN.md` reference or a functioning component.

## 2. Export the actual `DESIGN.md` and approve its bytes

Use the current design-system export control for the same reviewed Stitch project. Google documents [DESIGN.md export and import](https://blog.google/innovation-and-ai/models-and-research/google-labs/stitch-ai-ui-design/), but the public pages do not fix a control label or ZIP layout. Inspect the downloaded entries if it arrives as an archive. If the project offers no `DESIGN.md`, record the account or export limitation and stop this route. Do not create a handwritten file and describe it as Stitch's export.

Preserve the original file, its filename casing, project and screen IDs, export time and SHA-256. Replace this example path with the location of the real extracted file:

```powershell
Get-Item -LiteralPath '.\Stitch-export\DESIGN.md' | Select-Object FullName,Name,Length
Get-FileHash -Algorithm SHA256 -LiteralPath '.\Stitch-export\DESIGN.md'
Get-Content -LiteralPath '.\Stitch-export\DESIGN.md' -Raw
```

Confirm that `Name` is `DESIGN.md`, `Length` is nonzero and the complete text corresponds to the reviewed screens. Compare color roles and values, fonts and licenses, spacing, corners, component states, responsive rules, assets and accessibility requirements with both the screens and the owner's decisions. Mark omissions and conflicts as unresolved. If a needed rule is absent, correct the Stitch design and export again where supported. Have the owner approve the **exact export or revised reference revision and digest** before coding. Keep the raw export separately if the approved reference adds project-specific decisions.

## 3. Load the approved reference in Claude Code

Our guide to [creating an owner-approved DESIGN.md for Claude Code](https://bigchange.ai/blog/claude-code-owner-approved-design-md-guide) covers writing a visual specification from approved brand decisions. Here, retain the actual Stitch export as the starting artifact.

Place the approved file at `design-reference/DESIGN.md` in the owned repository, or record another project path. Hash that copy and compare it with the approved digest. If the owner approved an amended version, compare with that version's digest and retain the original export for provenance.

Read the project's existing `CLAUDE.md` before editing it. Add one line with a relative import path, adjusted for the actual location of the containing file:

```plaintext
For UI work, read @design-reference/DESIGN.md and check each changed component against its approved revision. Ask about unresolved rules.
```

Paste the line as ordinary text in `CLAUDE.md`, without a Markdown fence or backticks. [Anthropic's import documentation](https://code.claude.com/docs/en/memory) says quoted paths and paths inside code spans or fences are skipped; relative paths resolve from the containing file. In a fresh Claude Code session, inspect `/context` or `/memory` for the loaded project instructions, then request a read of the entire approved file. Check the tool result for the exact path, first and last lines and expected values. Recheck the local hash before editing. If access is denied or the file is missing or truncated, repair that specific problem and verify a complete read before proceeding. An instruction import guides the assistant; it does not validate the design or grant write authority.

## 4. Map rules into the existing styling system

Inspect the repository's component API, framework version and theme. Make a mapping from each approved design rule to an existing variable, token or component style. Keep unknown values unresolved. If the approved file has machine-readable tokens, the owner's repository permits a temporary npm package fetch, and the installed project uses Tailwind, Google's [experimental `design.md` CLI](https://github.com/google-labs-code/design.md) offers a lint and export route. The Windows alias is `designmd`. For confirmed Tailwind v4, run from the project root:

```powershell
if (Test-Path -LiteralPath '.\design-reference\tailwind-v4-proposed.css') { throw 'Proposed output exists; choose an unused filename' }
npx -p "@google/design.md" designmd lint .\design-reference\DESIGN.md
if ($LASTEXITCODE -ne 0) { throw 'DESIGN.md lint failed; stop before conversion' }
npx -p "@google/design.md" designmd export --format css-tailwind .\design-reference\DESIGN.md > .\design-reference\tailwind-v4-proposed.css
if ($LASTEXITCODE -ne 0) { throw 'Token export failed; inspect before retrying' }
Get-Content -LiteralPath '.\design-reference\tailwind-v4-proposed.css' -Raw
```

For confirmed Tailwind v3, use `--format json-tailwind` and a separate, unused `.json` output. The CLI describes those as a v4 CSS `@theme` block and a v3 `theme.extend` object, respectively. A successful export does not itself mean lint passed. Inspect each emitted value against the approved file before merging accepted values into the project's theme; run its original checks afterward. If the reference is prose-only, conversion fails, or the package fetch is not approved, map the approved values manually into the existing styling system and document each mapping. Never replace unrelated theme rules to make the export fit.

## 5. Implement and check the first component

Ask Claude Code to inspect the target files, approved reference, mapped theme and project commands before proposing a bounded edit. Review its path list, commands and proposed dependencies. Use the project's normal permission controls to authorize only the intended change:

```prompt
Implement [reviewed Stitch screen or interaction] as [first named component] at [approved paths]. Read all of design-reference/DESIGN.md revision [approved SHA-256] and use the approved mapping in [theme path]. Preserve [actual copy, links, data boundaries and behavior]. Implement [listed states] at desktop and phone widths. Show the full diff and the project's original check commands and results. Stop on a missing rule or conflict; do not invent backend connections, assets, fonts or extra pages.
```

Inspect every changed file and diff. Run the repository's actual build, type, lint and relevant interaction checks; record commands and results. Render the changed route at the target desktop and phone widths and in the required states. Compare it with the reviewed Stitch screens and approved file: colors by role, font and fallback, hierarchy, spacing, corners, assets, focus, disabled and error states. Check the code's theme values as well as the pixels. Independently operate controls and keyboard focus; inspect labels, contrast, clipping, links and any touched data behavior. Record each rule as matched, deviated, unverified or needing an owner decision, with its code location and screen state.

Give Claude a bounded correction for each concrete miss. Review the new diff, rerun affected checks and rerender the affected widths and states. If the design reference itself needs changing, obtain a new owner-approved revision and revisit the mapping. Hold acceptance when an essential interaction, contrast pair or target screen cannot be checked.

## 6. Reuse that revision for a second component

Choose a different small component in the same project. Record the starting code revision and hash `design-reference/DESIGN.md` again. In a fresh bounded request, require a complete read of the same file and inspect the read result before any edit:

```prompt
Read the complete design-reference/DESIGN.md and show the file-read result before editing. Confirm its SHA-256 matches [approved digest]. Implement only [second component] at [approved paths], preserving [actual copy, links, behavior and data boundaries]. Use the same approved rules and show the diff and original project check results. Stop if the reference changed or a rule is missing.
```

Review the second diff and rerun the project's checks. Render the second component at relevant desktop and phone widths and states. Compare its values and appearance with the approved file **and** the first component. Correct drift, rerun affected checks and inspect both results. If the owner approved a newer design reference between edits, record the new digest and recheck every earlier component touched by those changed rules.

The finish record contains the Stitch project and screen revision, real export and approved digest, inspected instruction import and two complete reference reads, both diffs and check outputs, desktop/phone/state comparisons for each component, corrections and remaining owner decisions. Keep the original code revision for rollback. Two checked components demonstrate this project's reviewed reuse; they do not establish automatic consistency for later work.

## Sources

- [Google Stitch DESIGN.md announcement](https://blog.google/innovation-and-ai/models-and-research/google-labs/stitch-design-md/) — Documents the file and open draft format; the reader verifies the actual export.
- [Google Stitch canvas announcement](https://blog.google/innovation-and-ai/models-and-research/google-labs/stitch-ai-ui-design/) — Describes the design canvas and DESIGN.md transfer; no fixed account export control is assumed.
- [Google design.md repository](https://github.com/google-labs-code/design.md) — Documents experimental CLI lint, Windows alias and Tailwind v3/v4 exports. Output still needs review.
- [Tailwind theme variables](https://tailwindcss.com/docs/theme) — Documents v4 @theme syntax; the reader checks the installed version.
- [Anthropic Claude Code project memory](https://code.claude.com/docs/en/memory) — Documents project import syntax and loaded-instruction checks.
- [Anthropic Claude Code workflows](https://code.claude.com/docs/en/common-workflows) — Documents planning before edits; actual project commands require inspection.
- [Anthropic Claude Code permissions](https://code.claude.com/docs/en/permissions) — Documents permission controls; edit authorization remains project-specific.
- [Anthropic Claude Code data usage](https://code.claude.com/docs/en/data-usage) — Account-dependent material handling must be checked by the reader.
- [Anthropic Claude Code costs](https://code.claude.com/docs/en/costs) — Account-dependent usage and billing; this guide measured none.