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

Google Stitch can generate a 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. Give it the approved assets and a brief that names the real task, content and states. For example:

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, 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:

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 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:

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 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 offers a lint and export route. The Windows alias is designmd. For confirmed Tailwind v4, run from the project root:

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:

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:

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.