Google Stitch Workflow

Use when working with Google Stitch through a disciplined MCP-first workflow. Prefer this skill for project inspection, controlled screen generation and edit...

Security Scan

This is a documentation/instruction-only skill that provides step-by-step operational guidance for using Google Stitch via an MCP workflow; it contains no code, no install, and requests no credentials, and its requirements match its stated purpose.

Purpose & Capability

The name and description promise disciplined guidance for Google Stitch via an MCP-first workflow; the bundle is instruction-only, contains only documentation and references, and does not request unrelated binaries or credentials — this is proportionate to a guidance skill.

Instruction Scope

SKILL.md focuses on prompt structure, generate/edit/variants discipline, and reporting conventions. It recommends inspecting project and screen metadata (project id, screen id, htmlCode, screenshots) and keeping local artifacts/state (run directories, last-active-screen file). These are reasonable for a workflow guide, but they imply the agent/operator will read/write local files or use a Stitch/MCP connector — the skill itself does not include or automate those actions.

Install Mechanism

No install spec or code files are present; nothing is downloaded or written by the skill itself, which is the lowest-risk model for a skills bundle of this type.

Credentials

The skill declares no required environment variables or credentials. That is consistent for documentation-only guidance, but the instructions assume an agent environment that already has access to a Stitch/MCP connector; you should verify how your platform provides that connector and which credentials/scopes it uses (those credentials are not part of this skill).

Persistence & Privilege

The skill does not request always-on presence, does not modify other skills or system-wide settings, and only suggests optional local persistence conventions for traceability. Those conventions are advisory and not enforced by the bundle.

Assessment

This skill is an operational playbook (no code, no installs, no secret requests) and appears coherent with its purpose. Before installing or using it, confirm that your agent/platform already has the Stitch/MCP connector and review that connector's credentials and scopes (the skill assumes access but does not provide credentials). If you plan to follow the local artifact conventions, be mindful that saved screenshots, HTML, or logs can contain sensitive data — store them securely and audit access. Finally, test workflows in a sandbox environment first to confirm the agent's actual MCP actions match the guide's expectations.

Use Google Stitch primarily as a design exploration and screen-iteration system. For greenfield apps, once a screen direction is accepted and exportable code is available in the active environment, use the generated HTML/CSS as the translation base rather than recreating the design from screenshots by hand.

This skill separates three concerns that are often conflated:

• verified MCP capabilities in the current environment
• browser-only Stitch product features
• optional local workflow conventions that improve traceability

Use this skill when the task involves one or more of:

• inspecting Stitch projects and screens before making changes
• generating a new screen from a text prompt
• refining an existing generated screen with small, controlled edits
• organizing a multi-screen redesign effort without losing revision history
• converting vague design requests into structured prompts

Do not assume the browser UI, the public product marketing, and the MCP surface expose the same operations.

When to use this skill

Use this skill when the task involves one or more of:

• inspecting Stitch projects and screens before making changes
• generating a new screen from a text prompt
• refining an existing generated screen with small, controlled edits
• organizing a multi-screen redesign effort without losing revision history
• converting vague design requests into structured prompts

Do not assume the browser UI, the public product marketing, and the MCP surface expose the same operations.

Do not use Stitch as the primary path when the real task is:

• implementing production UI code directly
• making deterministic pixel-perfect edits to an existing coded screen
• redesigning an app without reliable reference screens or screenshots
• planning an entire product in one step without screen-level iteration
• evaluating engineering feasibility without a prior visual direction

When not to use this skill

Do not use Stitch as the primary path when the real task is:

• implementing production UI code directly
• making deterministic pixel-perfect edits to an existing coded screen
• redesigning an app without reliable reference screens or screenshots
• planning an entire product in one step without screen-level iteration
• evaluating engineering feasibility without a prior visual direction

Important nuance:

• for an existing coded app, Stitch is usually best as a design reference and iteration surface
• for a new app with no established implementation, accepted Stitch exports can be the fastest way to seed the first real UI structure

Quick operating rules

• rewrite before acting — before any generate, edit, or variants call, rewrite the user request into a stronger design prompt or a tighter edit intent
• inspect before editing — always inspect the project and target screen first; verify whether the screen is actually generated content (if htmlCode exists, it's more likely editable)
• pick the operation class first — decide whether this pass is generate, edit, or variants; do not blur exploration, refinement, and branching in one move
• work one screen at a time — one short generation followed by controlled edits; keep one screen as the unit of iteration
• keep prompts short, explicit, and preservation-oriented — start with the smallest prompt that can produce a useful screen
• review the visual result before the next major step — review screenshots or visual artifacts immediately after each generate/edit; ask the user to choose using a human description, not an opaque screen ID
• move to code only after one direction is clearly accepted — confirm the visually reviewed canonical screen before export or translation; move to code only after the screen family is coherent
• stop repeating failing payloads — do not brute-force retries with the same parameters
• act as creative director — Stitch is the designer, you provide the direction
• define what must NOT change — the single most important iteration rule: tell Stitch what to keep, not just what to change
• hub-first for multi-screen projects — generate a hub screen first, derive all other screens via edit, never fresh generate siblings
• report state after every pass — after each generate/edit/variants step, report the project id, screen id, artifact location if any, a short design judgment, and the next recommended move
• treat wrapper enhancements as optional — not part of the Stitch MCP contract

Complete process order

This is the recommended sequence from blank canvas to accepted design:

1. Empathy → Who is the user? What should they feel?
2. Creative direction → Concrete vocabulary, metaphors, not abstract words
3. Prompt with direction → Describe what the site is and how it feels
4. Design system → Set color hierarchy, font hierarchy, corner radius in DESIGN.md
5. Layout → Use variants (Explore level) with scoped layout prompts
6. Copywriting → Generate real copy matching the creative brief
7. Iterate → One screen at a time, scoped refinements
8. Export/code → Only after the direction is clearly accepted

Before step 1, create a feature matrix. Map which features appear on which screen. Only start generating once the coverage is clear — this makes every generate/edit call a deliberate execution step, not a discovery. Three focused screens you've thought through beat ten screens you discover issues with during generation.

At the start of each pass, choose one operation class on purpose:

• generate for a new canonical screen
• edit for a focused improvement to an existing screen
• variants for controlled branching from a base direction

Skip steps and you'll iterate more later. Follow them and each step builds on the last.

---

Creative Direction

Creative direction framework

The single biggest lever for better Stitch results is direction before description. A generic prompt gives a generic screen. A directed prompt gives something you can actually iterate on.

1. Start with empathy

Before touching color, typography, or layout, answer two questions:

• Who is the user?
• What should they feel when they arrive?

Everything else flows from these answers.

2. Replace abstract words with concrete vocabulary

Bad: "make it look high-end", "patriotic", "sporty", "modern"
Good: "architectural limestone", "neoclassical", "ink on paper", "clay of an old track"

Concrete aesthetic words give Stitch something to build from. Abstract words give you the same generic output as everyone else.

Tip: Use an LLM (Gemini works well) to help craft prompts with specific design concepts and aesthetic descriptions. Feed it your empathy answers and ask it to return design vocabulary you wouldn't have thought of.

3. Use metaphors to find layouts

When stuck on layout, ask: "If my site were a physical object, what would it be?"

• A coffee table book → lookbook editorial layout with full-page imagery
• A newspaper → dense typographic grid
• A luxury travel magazine → large headings over cinematic photography

This bridges the gap between "I know what I want" and "I don't know what to prompt."

Design system as DNA

Stitch auto-generates a design system for every project. Treat it as the DNA of your design, not decoration. It covers colors, fonts, components, and — critically — a structured creative brief.

DESIGN.md

Stitch generates a DESIGN.md tab covering creative direction, color hierarchy with roles, typography rationale, elevation, components, and dos/don'ts. This is what drives the design system.

Treat DESIGN.md as a two-layer artifact:

• a token layer with the concrete values the system depends on
• a prose layer with the reasoning for what those values are supposed to do

Keep those two layers aligned. If the rationale and the token values drift apart, the design system stops being reliable for both Stitch and coding agents.

Think of tokens as named design decisions, not loose variables. primary is not just a hex slot; it is the role for the main ink of the product. body-main is not just a size; it is the role for default reading copy. The current value fills that role, but the role is the durable part.

What you can do with DESIGN.md:

• edit it directly in Stitch to course-correct
• have an LLM generate an improved one
• copy it to new projects for consistency (paste it into a new prompt and Stitch builds from it)
• copy it into your coding agent (VS Code, Cursor, etc.) as a rule set that maintains design consistency when translating Stitch output to real code

DESIGN.md portability pattern:

1. Generate a design in Stitch and let it create the DESIGN.md
2. Review and refine the DESIGN.md inside Stitch
3. Copy the DESIGN.md content
4. Paste it into your coding agent's context (system prompt, rules file, or inline)
5. Use it as the style authority when translating Stitch exports to production code

This bridges the gap between Stitch's design environment and your coding environment, ensuring the coding agent respects the same typography, color hierarchy, spacing rules, and component decisions.

This is the single most portable artifact in your Stitch workflow. Invest time in getting it right.

Creating a custom DESIGN.md outside Stitch:

1. Write a minimal design-system brief first: visual posture, intended mood, main user job, and 3-5 things the UI must not resemble.
2. Turn that brief into a compact DESIGN.md with:
   • YAML front matter for the durable tokens: color roles, typography, radius, spacing, and only the stable component rules
   • markdown sections for the why: overview, colors, typography, layout, components, and do's/don'ts
3. Keep the token layer concrete. Keep the prose layer directional. Do not mix them.
4. Define the baseline role anchors clearly:
   • primary for the main ink and core text emphasis
   • neutral for the canvas and emotionally neutral surfaces
5. In component rules, prefer references to roles over hardcoded raw values. A button should usually point at primary, tertiary, on-primary, or another named role instead of embedding a literal color directly.
6. Keep the Components section conservative. Encode the stable reusable rules, not every temporary visual exception.
7. In Stitch: Design Systems → Create New → paste the finished DESIGN.md → Save
8. Stitch visualizes the design system immediately — colors, fonts, spacing all rendered
9. Generate screens using this custom design system as the base

This pattern is useful when you've already brainstormed design direction with a coding agent and want to transfer that direction into Stitch.

If the copied DESIGN.md will become a real project artifact outside Stitch, validate it before treating it as authoritative:

npx @google/design.md lint DESIGN.md
npx @google/design.md diff DESIGN-before.md DESIGN-after.md

Use lint as part of the normal edit loop, not just as a final gate: read the current design system, make the change, lint it, fix the findings, then re-check. Use diff before and after meaningful revisions to catch token drift or accidental regressions in the design system itself.

Importing from an existing website:

Beyond pasting a URL for style hints in a prompt, you can import a website's design as a formal design.md file via the design systems panel: provide the URL and Stitch crawls the site, extracting style and typography into a structured design system. This gives you an editable, portable design foundation rather than a one-off style hint.

Color hierarchy (not just a palette)

Colors have jobs based on visual weight and importance. Reach for the role first, then the value that currently fills it. That keeps the design system semantic instead of turning it into a bag of swatches.

Primary and neutral are the anchor roles. In practice, primary usually carries the reading ink and strong emphasis, while neutral carries the background and surface system.

Colors have jobs based on visual weight and importance:

Role	Usage	Visual weight
Neutral	80-90% of the canvas — the background	Lightest
Primary	Headings, body text, core content	Dark, high contrast
Secondary	Subdued support text	Softer than primary
Tertiary	Accent, CTAs, hover states	Loudest, but used the least

The tertiary color is third in volume but first in visual pull. Choose it deliberately.

Font hierarchy

Stitch sets up three font slots: headline, body, and label.

Opinionated guidance:

• Choose fonts that match your creative direction, not just "what looks nice"
• Space Grotesk is great for labels and timestamps. It does not belong in headlines. (Stitch will put it there — override it.)
• A font like Public Sans works for both headline and body when you want official-but-approachable
• Match the font personality to the emotional goal

Corner radius as a design decision

Corner radius is not neutral — it communicates:

• More rounded → friendly, approachable, casual
• Sharp edges → editorial, serious, stationary-like

Decide based on the feeling you want, not a default.

---

Prompting & Generation

App vs Web toggle

Before generating, switch between App (mobile/narrow) and Web (wide/horizontal) in the Stitch UI. This fundamentally changes the output — Stitch composes a proper layout rather than stretching a design. Don't forget this toggle when switching between mobile and desktop targets.

Model selection & thinking mode

Stitch offers multiple generation modes. Pick based on where you are in the process:

Mode	When to use
Gemini Flash (GEMINI_3_FLASH)	Fast exploratory passes, iterating on direction
Gemini Pro (GEMINI_3_PRO)	Complex multi-screen dashboards, when quality matters more than latency
Redesign	You have a screenshot or existing site to work from
ID8	You only have a vague problem statement; Stitch helps you construct a plan
Live	Real-time conversational editing; changes appear as you chat (voice-based, AI sees your screen)

Thinking mode: Stitch 2.0 exposes a Thinking toggle alongside model selection. Thinking mode takes a few seconds longer but follows complex instructions significantly better than fast mode. Use it when:

• the prompt specifies detailed section-by-section layout
• the design has complex multi-region composition
• you need the output to match a specific structure, not just a general vibe

Tip: For complex apps with many screens, use Pro + Thinking for the first generation then Flash for quick iterations.

Component isolation

Stitch's strongest tendency is to generate full application layouts — sidebar, header, navigation, content — even when you only asked for a button. To counteract this, include this incantation when generating individual components:

"Design a single standalone UI component — do NOT generate a full application screen or layout. Show it isolated on a neutral background, like a component in a design system."

Also add: "Make sure all text is fully visible — do not truncate any labels or text with ellipsis."

This produces dramatically better results for component work.

First prompt: don't start blank

A common pattern from other AI design tools is to start with a blank page and build the design system manually first. This does not work well in Stitch. Starting with "build me a blank page with no design system" produces noticeably worse results than letting Stitch generate its own design system from a descriptive initial prompt.

Instead, include your theme and color choices directly in the first prompt:

"Build me a crypto dashboard with purple as the primary color in dark mode"

Stitch generates the design system (primary/secondary/tertiary/neutral colors, fonts, components) alongside the first screen. You can adjust everything afterward, but you get a much stronger starting point than starting from nothing.

Also: mobile designs currently tend to be higher quality than web. If output quality matters more than platform, consider generating mobile first.

Prompt construction: incremental enrichment

Don't write the final prompt in one shot. Build it up:

1. Start with the app description (1-2 sentences)
2. List the specific screens by name (e.g., "mission overview, trajectory, weather, mission log, system status")
3. Add core functionality per screen
4. Set the vibe with concrete adjectives
5. Optionally: use another AI tool (Gemini works well) to iteratively refine the prompt before pasting into Stitch — this produces significantly better results than writing the prompt directly in Stitch

Simple prompts work for simple apps. Complex dashboards benefit from upfront enrichment.

PRD + reference image pattern

The most reliable way to get a strong first generation is to combine a PRD (Product Requirements Document) with a reference screenshot:

1. Find a design you like on the web
2. Capture a full-page screenshot (use a browser extension like GoFullPage — wait for all animations/lazy loads to finish first)
3. Paste the screenshot into ChatGPT or Gemini with a prompt like: "I want to reference the design in the attached image to create a detailed PRD for a [type of app]. Include design principles, layout system, typography, color palette, components, and page structure."
4. Review and tweak the generated PRD
5. In Stitch: paste the PRD + attach the reference image together as your first prompt

This produces significantly better results than typing a design description from scratch. The PRD gives Stitch structural guidance (layout system, component hierarchy, color roles) while the reference image anchors the visual direction.

Tip: The PRD doesn't need to be long. Even a bullet-point outline covering layout, typography, and color intent is better than a vague one-liner. Stitch will generate its own design system from the PRD, so focus on what and why, not on exact pixel values.

Prompt structure template

Every good Stitch prompt has four layers. Omit one and Stitch fills the gap with generic defaults — that's where "AI slop" comes from:

1. Context — who and what: industry, audience, app reference ("Like Linear's dashboard")
2. Structure — layout and components: sidebar navigation, card grid, hero section, KPI cards with sparklines
3. Aesthetic — visual tone using precise keywords (see style keyword table below)
4. Constraints — device, format, what must NOT change

Style keyword reference

Stitch relies on precise design vocabulary. Use these keywords deliberately:

Keyword	What Stitch generates
minimal / clean	Lots of whitespace, restrained palette, simple geometry
editorial / magazine-style	Large typography, dramatic whitespace, museum-curatorial feel
brutalist / neobrutalist	Thick black borders, clashing colors, hard shadows, monospaced type
glassmorphism	Frosted translucent cards over colorful backgrounds, blur effects
dark mode	Dark backgrounds with light text, often paired with accent colors
premium / luxury	Restrained palette, serif typography, generous spacing
playful / consumer	Rounded shapes, bright colors, friendly illustrations
vintage	Texture, paper grain, serif type, aged feel
retro	Modern homage to past era (80s synthwave, pixel art, neon)

Vintage ≠ retro. Vintage gives you a 19th-century cookbook. Retro gives you 80s neon. Be specific.

Color directions: monochromatic, neutral with accent, vibrant on dark, pastel, muted/earthy — or specific: "indigo accent", "emerald green", "warm amber"

Section-by-section prompt pattern

For best results with complex layouts, structure the prompt as:

1. Context line — device and app type: "A mobile dashboard for a crypto tracking app"
2. Aesthetic line — visual direction: "dark mode aesthetics with neon purple and green accents"
3. Section-by-section layout — each section gets its own sentence: "Top section shows total portfolio value, below that a graph showing a 7-day trend"

Example (web): "A modern clean landing page for a SaaS productivity tool called Flowstate. Wide hero section with a headline 'focus faster' subtext and primary blue CTA button. Below, a three-column feature grid with icons, minimalist aesthetics with lots of white space."

This pattern works better than listing features without spatial context.

Adjective-driven mood language

Stitch relies on adjectives to identify mood rather than exact structural descriptions. "Warm, inviting, premium" works better than "rounded corners, 16px padding, serif font." When prompting, prefer mood and intent language first, then add structure afterward.

URL-based style extraction

Two approaches, depending on depth:

Quick (paste in prompt): Paste an existing website URL into Stitch's prompt area. Stitch extracts the color scheme, typography, and general visual vibe as a starting point. This avoids reinventing a design language that already exists.

Structured (import as design.md): Via the design systems panel, provide a URL and Stitch crawls the site, extracting style and typography into a structured design system file. This gives you an editable, portable design foundation rather than a one-off style hint.

Wireframe-to-design from photos

Upload a photo of a paper sketch and use this prompt pattern:

"Turn this wireframe into a [fidelity level] [platform] [screen type], [aesthetic direction]"

Example: "Turn this wireframe into a high fidelity iOS login screen, clean white background." Stitch converts scribbles into proper UI elements.

Use Pro + Thinking for wireframe uploads. Flash produces noticeably weaker results with sketch/wireframe inputs — the output tends to look flat and generic. Pro + Thinking interprets spatial relationships from drawings significantly better.

Expect variable quality from hand-drawn input. Results depend heavily on sketch clarity and prompt specificity. The impressive examples on social media often come from clean, well-structured sketches combined with detailed prompts.

---

Iteration & Refinement

Continue suggestions

After generating a screen, Stitch suggests one-click follow-up edits (e.g., "Add a buy/sell button for quick trades"). Check these before writing your own follow-up prompt — they're often useful and faster than crafting a custom edit.

Variants

Variants let you generate multiple takes on a design and scope the exploration.

Creativity levels:

Level	Behavior	When to use
Refine	Small tweaks, close to original	Polishing an accepted direction
Explore	Balanced creativity — the sweet spot	Finding layout and imagery options
Reimagine ("YOLO" in Stitch UI)	Wild reinterpretation	Breaking out of a rut, early exploration

Scoping: Scope variants to specific aspects: layout, color scheme, images, text, or font. This prevents unwanted changes in areas you've already accepted.

Best practices:

1. Generate 3-5 variants (adjustable count in the UI)
2. Expect artistic flops — not every variant will be usable. This is normal.
3. Expect complete failures — some variants may produce blank, broken, or empty results. Don't analyze failures; just regenerate.
4. Don't pick one winner — pick elements from multiple screens and compose
5. Everything in Stitch is a component; you can mix and match across variants
6. Use scoped prompts to refine specific aspects without breaking what works
7. Use the custom instructions field in the variant dialog for specific guidance

Note: generate_variants through MCP may still have reliability limitations (see capability boundaries). Variants are most reliable through the browser UI.

Annotate: visual targeted editing

The Annotate feature lets you drag-select a region of a generated screen and describe changes for just that area. This is a visual alternative to text-based element targeting — useful when you can see what needs to change but don't want to re-describe the full context.

Best for: layout tweaks in a specific section, repositioning elements, adjusting spacing in one area without affecting the rest.

Direct inline editing

You don't always need the prompt box. Click any element on a generated screen to:

• Edit text directly — click and type, no regeneration needed
• Use AI on a specific element — targeted changes without affecting the whole screen

This is the fastest path for small copy changes, label fixes, or tweaking a single button. Use it before reaching for a full prompt-based edit.

Quick style adjustments

Select a screen → Edit → Edit Theme to open a right panel with color and corner radius controls. Faster than re-prompting for small style changes. You can also right-click any screen for quick access to editing features and keyboard shortcuts.

Multi-screen hub-first pattern

For multi-screen projects, the critical rule: generate a hub screen first, then derive all other screens via edit — never fresh generate siblings.

Why: generate invents everything from scratch (layout, colors, spacing, typography). edit takes the source screen as the visual basis and changes only what you describe. Navigation, typography, and color palette stay consistent.

Recommended flow:

1. Generate the hub screen → review carefully
2. All further screens of the same concept → edit from the hub
3. Max 1-2 changes per edit prompt — too many changes = unpredictable results
4. Even elements you did NOT mention can change in an edit. Fewer changes = more stable output.

During the concept phase, 3-4 consistent core screens are enough. Full screen coverage only after the concept is approved.

Screen review loop

After each generate or edit, categorize issues systematically:

Category	Examples	Action
Stitch-fixable	Missing section, wrong layout order, major color error, wrong navigation	Edit prompt (max 1-2 changes)
Post-export fix	Exact pixel spacing, icon details, typography fine-tuning, persistent content hallucinations	Note it, move on

Decision tree:

• Stitch didn't fix it after 2 edits → note as post-export fix, move on
• Detail work (shadows, exact radii, pixel spacing) → directly note as post-export fix, don't waste edit budget
• Structural issue (section missing, navigation wrong) → Stitch edit

The user decides which tool to use for post-export fixes (Figma, code, etc.). Do not prescribe a tool.

Sequential wizard / multi-step pattern

Generate each step individually, using the previous step as base:

"Use the existing Step 2 screen as the base. The following elements must stay exactly identical: [header, sidebar, progress indicator, page title]. Change ONLY these elements: [form content, step number, CTA label]."

Without explicit constraints, Stitch will change headers, titles, and layout between steps.

Copywriting as a design step

Generic placeholder text makes even a beautiful layout feel like a template. Real copy makes the design feel real.

When: After the creative direction and design system are stable, but before the final design pass. Copy is not a finishing touch — it's a structural element.

How:

1. Use an LLM or agent skill with your DESIGN.md as context
2. Include the app description, community aspects, and emotional goals
3. Get multiple options for headlines, subheadlines, CTAs
4. Review and revise before feeding back into Stitch
5. Paste the copy into a variant prompt scoped to text content

The copy should match the creative brief. If your direction is "prestigious journal," the copy should sound like one.

Multi-page expansion

After generating a page with navigation (sidenav, tab bar, etc.), rapidly scaffold the rest of the app:

"Build me a page for each of the items in the left hand navigation"

Stitch generates all sub-pages in one shot, carrying the design system forward. Some pages may introduce inconsistencies (e.g., a top nav on one page when the rest use a sidenav) — expect minor cleanup.

Brand consistency: When adding pages, you don't need to re-specify the brand or design language. A minimal prompt like "design a second page for pricing" is enough — Stitch carries the color scheme, typography, and brand name forward.

Mobile-from-web conversion

After designing a web/desktop screen, use Generate → "build a mobile app version" to have Stitch adapt the layout for mobile. This produces a separate mobile screen based on the same design system.

Expect some inconsistencies (chart types, minor layout differences) — treat it as a starting point, not a pixel-perfect responsive version.

Sketch-to-design workflow

Upload a sketch or wireframe in the Stitch Web UI, then tell the agent:

"I uploaded a sketch called [title]. Edit it to [desired changes]."

The agent finds the screen by title via list_screens and applies edits via the API.

Use Pro + Thinking for sketch/wireframe uploads — Flash produces noticeably weaker results with drawn inputs.

Live mode: voice-driven design exploration

Stitch's Live mode lets you talk to the AI in real-time while it sees your screen. It can suggest design changes, adjust layouts, and generate new versions — all through conversation.

Good for:

• quick exploratory direction changes ("make the text more luminous")
• getting the AI's opinion on readability or layout issues
• hands-free iteration when you're reacting visually

Not good for:

• precise, scoped edits (use text prompts or direct inline editing instead)
• complex multi-step instructions (the AI may drift)

Rule of thumb: Live mode is for creative exploration. Text prompts are for precise control. Direct editing is for surgical changes.

Redesign as style guide, not copy

Stitch 2.0's redesign feature does not replicate the source screenshot. It uses it as a style guide: pulling patterns, component placement, and design language, then applying them to your original content.

Tip: Use a full-page screenshot tool (e.g., GoFullPage) instead of capturing section-by-section. One full-page reference gives Stitch the complete design context in a single shot.

Cross-device preview

Before exporting, click the Preview button to see your design on phone, tablet, and desktop form factors. This catches responsive issues early. Make this a mandatory step before any export to AI Studio or code translation.

Cross-device preview

Before exporting, click the Preview button to see your design on phone, tablet, and desktop form factors. This catches responsive issues early. Make this a mandatory step before any export to AI Studio or code translation.

Heat map (attention audit)

Select a generated screen → Generate → Predicted Heat Map to see where users' eyes will land first. Use this as a quality gate: if key elements (CTAs, primary info) aren't in high-attention zones, iterate before moving to code.

Heuristic: "If your buy button isn't glowing on the heat map, fix the design before you code it."

Known issue: The heat map may generate for the wrong page or create a new page instead of analyzing the selected one. Verify which screen it actually analyzed before trusting the results.

Prototype mode tips

After generating pages, select 2+ screens and click Prototype to get an interactive click-through:

• Stitch auto-connects screens based on navigation elements
• Turn on hotspots to see clickable areas
• Switch between mobile/tablet/desktop to verify responsive behavior
• Select a specific element → "Change with AI" for targeted edits (e.g., add animation) without regenerating the whole screen
• Edit text directly on elements without re-generation
• "Imagine a new screen" suggests new pages based on your existing design context
• After adding new screens manually, use connect to screen to wire up navigation

This is a browser-only feature but invaluable for validating user flow before coding.

---

Export & Code Translation

Export paths

Export path	Direction	Best for
Google AI Studio	One-way push	Simple apps (1-2 pages), quick prototyping
MCP connection	Bidirectional	Ongoing projects, multi-page apps, iterative development
Download zip	One-time	Offline work, custom build pipelines
Copy code	One-time	Quick paste into existing project
Figma	One-time	Design handoff to designers
Project brief	One-time	Requirements document for stakeholders

AI Studio pipeline

The simplest end-to-end path for getting a working website from a Stitch design:

1. Design in Stitch — finalize the direction, verify via cross-device preview
2. Export → Build with AI Studio — Stitch automatically uploads images, a markdown file, and a prompt. No manual copying needed.
3. Press Build in AI Studio — generates a functional website matching the design
4. Verify — check mobile/desktop views in AI Studio, test interactions
5. Publish — create a cloud project (may require billing), get a live URL
6. Customize — set up custom domain if needed

This is the "Vibe Design → Vibe Coding" pipeline: zero manual design, zero manual coding.

AI Studio as a faster iteration surface: Once you export to AI Studio, it becomes faster than Stitch itself for refinements:

• Changes typically take 30-60 seconds vs. 2+ minutes in Stitch
• Screenshot-anchored editing: paste a screenshot of the specific section to change, describe the edit. The image pins context so the AI knows exactly what to modify.
• AI Studio preserves your full HTML/CSS, so every edit updates the actual code

Practical flow: Design direction in Stitch → export to AI Studio → refine details there → publish or copy code.

AI Studio export gotchas:

• Select all screens before exporting. By default, AI Studio may only receive the active screen.
• Export page-by-page for complex apps. Sending 5+ complex screens at once can overload AI Studio (12+ minute builds with missing content).
• AI Studio export is one-way. Changes in Stitch after export don't sync back.

Bidirectional MCP workflow

MCP creates a two-way connection between Stitch and your coding agent:

1. In Stitch: Export → Set up MCP → Choose your tool → Create API key
2. In coding agent: Add MCP server → Search "Stitch" → Install → Paste API key
3. Available tools: create/list/get projects, get/generate screens, pull design files, sync updates
4. Key benefit: edit in Stitch → pull changes in coding agent → edit code → push back. No re-export needed.

Recommended hybrid flow for larger projects:

1. Design in Stitch
2. Initial export to AI Studio for the first working prototype
3. Push to GitHub
4. Open in coding agent (Antigravity, Claude Code, Cursor)
5. Connect MCP for ongoing bidirectional iteration

Figma export

Export to Figma: Export → Figma → Convert → Copy frame → Paste in Figma. The resulting auto layout is usable — better than most AI design tool exports — though some elements may be hidden or not fully responsive. Good enough for design handoff and developer inspection.

Review gate before code translation

Do not port a Stitch output into code until these conditions are true:

• required elements are still present
• the primary user task is clearer than before
• mobile density and hierarchy are acceptable
• the screen fits the rest of the project direction
• the design can be implemented coherently in the current application architecture

If the answer is not clearly yes, keep iterating in Stitch.

For greenfield translation from exported Stitch code, also check:

• the exported code represents the accepted direction, not an older candidate
• the layout system is coherent enough to preserve rather than rewrite immediately
• the token layer can be mapped into the target project's theme system
• there is a plan to replace placeholders and hardcoded demo content with real data
• the team will translate deliberately instead of pasting large exports blindly
• all required npm dependencies are installed before integration
• hardcoded colors/sizes have been replaced with project theme tokens

Design system file injection

When the SDK doesn't support design_system_id in generate/edit calls, use this workaround: load a design system markdown file and append its content to the prompt. This carries design tokens (colors, typography, spacing rules) into each generation without relying on Stitch's built-in design system panel.

Dependency check during integration

When integrating Stitch output into a codebase, check whether the generated code uses libraries not yet installed (e.g. recharts, framer-motion, lucide-react). Run npm install <pkg> before integration to prevent build failures.

Also check whether the generated code uses hardcoded colors or sizes that conflict with the project's existing theme — replace them with CSS variables or design tokens before saving.

Architecture-aware component placement

When integrating components, respect the project's architecture:

• Standard: src/components/<ComponentName>.tsx
• Hexagonal/modular: src/modules/<domain>/components/<ComponentName>.tsx
• Feature-based: src/features/<feature>/components/<ComponentName>.tsx

Don't blindly place everything in src/components/ — detect the project's convention first.

Shadcn UI integration

For converting Stitch designs into production-quality component apps:

1. Set up the Shadcn MCP before building (provides tool calls for component operations)
2. Install Google's Shadcn UI skill — a detailed guide for converting Stitch output to Shadcn components
3. Add instructions to your agent's config so Stitch MCP output automatically flows through the Shadcn skill
4. Specify additional registries for premium components (e.g., glassmorphism, motion primitives)
5. Workflow: specify the Stitch project name → agent fetches the project → loads Shadcn skill → implements with MCP tool calls + registries

This produces interactive, production-ready apps from Stitch designs in one shot rather than static HTML.

---

Autonomous Agent Pipeline

Google provides three skills for agent-connected Stitch workflows:

1. Enhanced Prompt skill — transforms vague prompts into Stitch-optimized prompts using adjective-based mood language and Stitch-specific keywords
2. Stitch Loop skill — autonomous iterative building using Chrome DevTools; maintains prompt tracking across stages
3. React Component skill — converts Stitch's monolithic HTML export into modular React components with validation scripts

Recommended pipeline order for coding agents:

1. Enhanced Prompt → convert your vague prompt into a Stitch-specific one
2. Stitch Loop → build the design via MCP (generates design system first, then actual design)
3. React Component skill → break the monolithic export into modular components

Add these steps to your coding agent's config file (e.g., Claude.md) so the pipeline runs automatically when you request a new screen.

---

MCP API Reference

Capability boundaries

Verified MCP capabilities (default safe surface):

• list_projects
• get_project
• list_screens
• get_screen
• create_project
• generate_screen_from_text
• edit_screens

Known weak or unverified areas — treat as unstable until revalidated:

• generate_variants — reliable through browser UI (see Variants section), less predictable via MCP
• screenshot-driven redesign through MCP
• prototype creation through MCP
• browser-style canvas operations beyond basic project and screen inspection

Browser-only product features — do not infer MCP can perform these:

• image or screenshot redesign
• prototype-oriented workflows
• broader canvas interactions
• newer browser-facing product features

Parameter discipline

The MCP surface is parameter-sensitive. Incorrect casing or identifier shape can produce generic invalid-argument failures.

deviceType: Use uppercase enum values when explicitly setting a device: "MOBILE", "DESKTOP". If uncertain, omit the parameter instead of guessing.

modelId: Use only verified model identifiers for direct MCP calls. Known working values: "GEMINI_3_FLASH", "GEMINI_3_PRO". If a local wrapper maps model names differently, treat that as wrapper-specific behavior, not a direct MCP guarantee.

selectedScreenIds: For edit_screens, pass bare screen IDs rather than full resource names.

Example:

{
  "projectId": "15190935684505273965",
  "selectedScreenIds": ["69b3228b6c5f4b9f9efceea4b6a30168"],
  "deviceType": "MOBILE",
  "prompt": "Make the primary button darker and add a small secondary text link below it."
}

Failure handling

Request contains an invalid argument. — Check in this order:

1. deviceType casing
2. modelId spelling
3. selectedScreenIds shape
4. whether the screen is genuinely editable generated output
5. whether the prompt is trying to change too much at once

Long-running operations may still complete even when the client appears to fail. Re-check list_screens, inspect any likely new screens, and avoid blind re-submission.

Generation or edit timeout: generate_screen_from_text can take 2-10 minutes. The API may drop the TCP connection after ~60 seconds even though the generation continues server-side. The client sees a failure, but the screen may appear in the project moments later.

Safe reconciliation pattern:

1. do not immediately resend the same request
2. re-check list_screens
3. inspect whether a new screen appeared
4. retry only if no result landed
5. if retrying, use exponential backoff — don't brute-force with identical parameters

Incomplete or lagging screen lists: list_screens may lag behind a successful operation. If the originating call indicated success, re-check before retrying. Do not assume immediate list lag means failure.

HTTP-level errors:

Error	Likely cause	Action
401 Unauthorized	Token/API key expired	Refresh auth, retry once
400 Bad Request	Invalid payload or vague prompt	Check parameters, refine prompt
429 Too Many Requests	Rate limit	Wait 60s, retry with backoff

---

Workflows

Workflow A: inspect before editing

Before any edit:

• inspect the project
• inspect the target screen
• verify whether the screen is actually generated content

Practical heuristic:

• if htmlCode exists, the screen is more likely to be safely editable
• if the target is only an uploaded image or reference asset, do not assume edit_screens will behave well

Workflow B: generate first, then refine

For new directions:

1. create or choose the right project
2. generate a first screen with the minimum safe parameter set
3. review output quality
4. move to small edits rather than repeating large generation prompts

Default safe starting point: projectId + a short, structured prompt. Then add deviceType or modelId only when there is a reason.

Workflow B2: greenfield app bootstrap from Stitch exports

Use this when the product is new enough that there is no meaningful coded UI to preserve yet.

1. generate the canonical screen family in Stitch first
2. get explicit acceptance on the direction before broad implementation
3. if code or HTML export is available in the active environment, download it
4. read the export completely before rewriting anything
5. translate the exported structure into the target stack instead of eyeballing screenshots
6. keep the layout system, spacing logic, token choices, and section structure where they are sound
7. replace hardcoded content and brittle markup gradually, not all at once
8. add the real app concerns after translation: data flow, typing, state, accessibility, dark mode, tests

Use this path especially when:

• the app is being built from scratch
• Stitch generated a strong screen family quickly
• the main value is the concrete composition, hierarchy, and token choices
• recreating the same layout manually would be slower and less faithful

Do not treat the export as production-ready final code. Treat it as a high-fidelity implementation seed.

Workflow C: full-app redesign

For an existing product redesign:

1. create a dedicated Stitch project
2. define the main screen families
3. generate one canonical screen per family
4. refine those canonical screens with preservation-first prompts
5. only then add alternate states and edge cases
6. move to code after the family set is coherent

This is slower than opportunistic one-off generation, but it reduces design drift.

Workflow D: reference-driven redesign

When redesigning a real app:

• gather reliable reference captures first
• work one screen family at a time
• name the relevant reference images explicitly in the prompt
• treat those references as the source of truth for current structure

Good pattern:

Use the uploaded real app references in this project.
The relevant images are named today_top.png, today_day_actions.png, and today_meals_mid.png.
Those images show what exists now.
Keep the real structure and improve only hierarchy, spacing, and polish.
Do not invent new sections.

Workflow E: visual review before further iteration

Use this when the session already has multiple candidate screens or when the next edit would otherwise be ambiguous.

1. use list_screens to find the likely targets
2. use get_screen to inspect candidate screens
3. when a screenshot or visual artifact is available, review it before the next major edit
4. ask the user to choose using a human description of the screen, not only an opaque ID
5. continue only after the canonical target is clear

Workflow F: decide whether to stay in Stitch or move to code

Stay in Stitch when:

• the information architecture is still drifting
• the visual hierarchy is still weak
• multiple screen directions are still being explored
• the user is reacting to screenshots rather than implementation details

Move to code when:

• one canonical screen direction is accepted
• the required elements are stable
• the remaining work is implementation fidelity rather than design exploration
• the screen can be implemented coherently in the target stack

For greenfield work, prefer this move-to-code order:

1. generate mobile and desktop canonical screens separately when both matter
2. accept the visual direction
3. export or download the generated code artifact when available
4. translate that artifact into the real stack
5. only then start screen-by-screen product hardening

---

Appendix

Naming guidance for larger projects

If the project will contain many screens, use stable ordered titles from the start.

Recommended pattern:

• 01 Onboarding - Welcome
• 02 Onboarding - Personal Info
• 10 Today - Main
• 20 Progress - Overview
• 30 History - Browse
• 40 Settings - Profile

This improves canvas scanning and reduces later cleanup.

What a good Stitch pass should produce

A successful pass should leave the session with:

• one clearly identified target project
• one clearly identified canonical screen or small set of candidate screens
• the exact prompt or edit intent that produced the result
• a short judgment on whether the result is accepted, rejected, or needs another small iteration

After each generate/edit/variants, report to the user:

• the project and screen IDs
• the output location (if artifacts were saved)
• a short design assessment
• the recommended next step

If those artifacts are missing, slow down and re-establish state before continuing.

Not recommended

• copying browser-product claims into MCP instructions without revalidation
• starting with a "blank page, no design system" prompt
• skipping the empathy step and jumping straight to colors and layouts
• using Space Grotesk for headlines (labels and timestamps only)
• treating copywriting as a final polish step instead of a structural design element
• picking one variant winner instead of composing from multiple variant elements
• using design boards or mood boards as substitutes for real app screens in a product redesign
• attempting to redesign a whole app from memory in a single prompt
• exporting 5+ complex pages to AI Studio all at once (causes overloading and missing content)
• forgetting to select all screens before exporting to AI Studio
• moving into implementation code before the design family is coherent
• trusting the heat map output without verifying which screen it actually analyzed
• rebuilding an accepted greenfield Stitch design from screenshots when a usable export already exists
• using exact structural descriptions instead of mood adjectives in prompts
• taking section-by-section screenshots for redesign — use full-page captures instead
• uploading a screenshot and asking Stitch to add something to it — Stitch regenerates the entire screen, losing consistency. Instead: generate the addition in isolation, integrate elsewhere (Figma or code)
• using multiple screens in one prompt — produces broken theming, incomplete outputs, errors. One prompt = one screen or one component
• using Reimagine/NanoBanana for small changes — it redesigns everything. Use for full overhauls only
• trusting generated content blindly — Stitch invents copy, subtexts, badges, status labels that weren't requested
• long prompts over 5000 characters — Stitch truncates or omits elements. Keep focused, iterate instead
• letting design drift across edits — after 3+ edits in a session, add: "Use the existing design system established in this project. Do not create new styles."

Google screenshot URL size parameters

Stitch returns screenshot URLs on lh3.googleusercontent.com. Append these suffixes to control resolution:

Suffix	Result
=w780	Full mobile design width (good default)
=w1440	Full desktop design width
=s2000	Max 2000px on longest side
(no suffix)	Thumbnail only (~168px wide)

Optional local workflow enhancements

If you want aliases, execution artifacts, derivation history, or last-active-screen state, use references/local-workflow-conventions.md.

These are useful for traceability, but they are optional and not part of the Stitch MCP contract.

References

• Prompt reference: references/prompt-structuring.md
• Visual review and artifacts: references/visual-review-and-artifacts.md
• Redesign prompt patterns: references/redesign-prompt-patterns.md
• Local workflow conventions: references/local-workflow-conventions.md
• Style keywords: see the Style keyword reference table in the Prompting & Generation section

Keep the main skill focused on operating rules. Use the prompt reference only when the request needs prompt shaping or prompt repair.