StitchFlow

Use this skill when the user wants to create a new screen, refine an existing one, generate design variants, or export local HTML and screenshots through Stitch.

It prefers native Stitch MCP tools when they are available in the current agent session, and falls back to the local toolkit at ${STITCH_STARTER_ROOT:-$HOME/.agents/stitch-starter} when they are not.

Local setup

• Toolkit root: ${STITCH_STARTER_ROOT:-$HOME/.agents/stitch-starter}
• API key is expected in ${STITCH_STARTER_ROOT:-$HOME/.agents/stitch-starter}/.env
• Outputs are saved to ${STITCH_STARTER_ROOT:-$HOME/.agents/stitch-starter}/runs
• The latest single-screen result is tracked in ${STITCH_STARTER_ROOT:-$HOME/.agents/stitch-starter}/runs/latest-screen.json

Native MCP setup

If the current client exposes Stitch MCP tools such as create_project, generate_screen_from_text, generate_variants, and get_screen, use those tools first. Native MCP avoids local SDK transport issues and is the most reliable path in Codex after the client has been restarted with the Stitch MCP server configured.

For Codex, a minimal MCP config looks like this:

[mcp_servers.stitch]
url = "https://stitch.googleapis.com/mcp"
enabled = true

[mcp_servers.stitch.http_headers]
"X-Goog-Api-Key" = "<your Stitch API key>"

Restart the client after changing MCP config so the stitch tools are loaded into the session.

When to use

• The user says to use Stitch or StitchFlow
• The user wants a screen generated from a brief, spec, or rough idea
• The user wants design variants before implementation
• The user wants targeted visual edits to a generated screen
• The user wants HTML and screenshots exported locally for review

Workflow routing

• New screen from a prompt or brief: Read text-to-design
• Targeted changes to an existing Stitch screen: Read edit-design
• Multiple directions from one base screen: Read variants

Core rules

1. Before any Stitch command, rewrite the user request into a stronger design prompt.
2. If the user already has a codebase or UI context, inspect it first and carry that context into the prompt.
3. Prefer DESKTOP by default unless the user clearly asks for mobile or tablet.
4. For first-pass exploration, prefer one generated screen plus 3 variants.
5. If a screen is already close, prefer edit over full regeneration.
6. Always tell the user where the resulting files were saved.
7. Never print or expose STITCH_API_KEY or .env contents.
8. When native MCP returns downloadUrl values, save the HTML and screenshot locally into the normal runs/ artifact layout before reporting completion.

What good output looks like

• the brief is rewritten into a stronger design prompt
• the right Stitch workflow is chosen: generate, edit, or variants
• the command completes and saves artifacts locally
• the response includes project id, screen id, output folder, and what to do next

Prompt shaping

Use prompt-keywords to translate vague requests into design language Stitch understands better.

Structure prompts like this:

[overall vibe, product intent, and audience]

Platform: [web/mobile], [desktop/mobile]-first

Page goal:
- what the screen is for
- what primary action matters most

Page structure:
1. Header / navigation
2. Main content / hero / dashboard body
3. Secondary content
4. Footer / actions / supporting detail

Visual direction:
- palette roles
- typography tone
- spacing density
- component style

After running Stitch

Report:

• the command used at a high level, not the secret env
• the project and screen ids
• the output folder under ${STITCH_STARTER_ROOT:-$HOME/.agents/stitch-starter}/runs
• the HTML and image artifact paths if they were downloaded
• a short design assessment and the best next step

References

• cli-usage
• prompt-keywords