Stitch Screens

Owns screen generation from text for the Google Stitch MCP server (stitch, tools exposed as mcp__stitch__<tool>). This skill covers generate_screen_from_text only. For changing a screen that already exists, use stitch-iterate if installed, or call edit_screens (projectId, selectedScreenIds, prompt) for refinements and generate_variants (projectId, selectedScreenIds, prompt, variantOptions) for alternatives directly — both are long-running and the protocol below applies to them unchanged.

Pre-flight: resolve before you generate

Do not call generate_screen_from_text until these are settled:

1. projectId. Required, bare id with no projects/ prefix (e.g. '4044680601076201931'). If you don't already have it, resolve it with list_projects (and create_project only if nothing existing fits) — see stitch-projects if that skill is installed, or call those tools directly otherwise.
2. The design system assetId. Optional on the tool signature, but treat it as required in practice. Pass it as designSystem: "assets/{id}" — with the assets/ prefix, unlike almost every other id this tool touches. Obtain the id via get_project or list_design_systems. The tool's own documentation states a design system "should always be configured for design consistency," and skipping it is not free: a screen generated without one drifts stylistically from the rest of the project, and the only fix afterward is a full apply_design_system pass, which itself needs screen instance ids from get_project — a strictly more expensive path than just passing designSystem up front. If the user explicitly says the screen is disposable or a one-off throwaway, it's fine to omit designSystem and accept the default design system; otherwise resolve it first.
3. deviceType. Optional: DEVICE_TYPE_UNSPECIFIED | MOBILE | DESKTOP | TABLET | AGNOSTIC. Decide this once per project and keep it consistent across every screen you generate for that project — mixing MOBILE and DESKTOP screens within one project produces a visually incoherent set. If the user hasn't said, ask, or infer it from context (e.g. "an app screen" leans MOBILE, "an admin panel" leans DESKTOP) rather than leaving it unspecified by default.

Before writing any non-trivial prompt for generate_screen_from_text, read references/prompting.md. It has the full anatomy of an effective Stitch prompt, a weak-vs-strong comparison table, and ready-to-adapt example prompts for common screen types — do not improvise prompt structure from scratch when that reference exists.

The long-running protocol

generate_screen_from_text is long-running and its own documentation is explicit about how to handle that. Three rules, non-negotiable: