Stitch Workflow

This is the entry point for multi-step Google Stitch work (MCP server stitch, tools exposed as mcp__stitch__<tool>). It does not do the design work itself — it sequences the specialist skills (stitch-projects, stitch-design-system, stitch-screens, stitch-iterate, stitch-components, stitch-storybook, stitch-to-code) and tracks the identifiers that flow between them. When a request maps cleanly onto one step, hand off to that specialist skill and let it own the call; use the fallbacks in the routing table below only when the specialist is not installed.

Canonical end-to-end sequence

1. Resolve or create a project. Call list_projects before create_project to avoid duplicating an existing project. Delegate to stitch-projects.
2. Establish a design system before generating any screens. Delegate to stitch-design-system (create, upload a design.md, or derive one from an existing screen instance).
3. Generate screens against that design system. Delegate to stitch-screens, passing the design system's assetId into generate_screen_from_text's designSystem parameter.
4. Iterate. Refine screens with edit_screens or explore alternatives with generate_variants. Delegate to stitch-iterate.
5. Route out of Stitch. Once screens and the design system are stable, there is no single next step — what the user wants determines which of these to do, and they are not strictly sequential: export design tokens and/or a DESIGN.md from the design system (delegate to stitch-design-system), slice a generated screen into reusable framework components (delegate to stitch-components), scaffold or extend Storybook with those components and compose page stories (delegate to stitch-storybook), and/or hand off to stitch-to-code for full application code. stitch-components and stitch-to-code are alternative routes to code, not sequential steps: stitch-components produces a reusable component library, stitch-to-code produces application code, and a user may want either, both, or neither.

Do not reorder steps 2 and 3. Skip step 2 only if the user explicitly says the screen is disposable/throwaway and consistency does not matter — otherwise call it out and default to establishing a design system first.

Exporting out of Stitch

The resolved design tokens (namedColors, typography, spacing, bodyFontFamily/headlineFontFamily/labelFontFamily) and the full DESIGN.md text (designTheme.designMd) both come back inside designTheme from get_project (name: "projects/{id}"). There is no dedicated export tool: exporting a DESIGN.md means reading designTheme.designMd from that response and writing it to a file yourself. designMd is not always present, so check that the field actually came back before telling the user an export succeeded. Delegate the detail work here to stitch-design-system; without it installed, the get_project call above is the fallback.

A minimal happy-path call sequence looks like this (ids are illustrative placeholders, not real values):