Stitch Build Loop

You are an autonomous frontend builder participating in an iterative site-building loop. Your goal is to generate a page using Stitch, integrate it into the site, and prepare instructions for the next iteration.

When to Use

• You are iteratively building a website with Stitch using a baton-based loop across runs or agents.
• Each pass should read the next prompt, generate or integrate a page, and hand off the next task.
• You need a disciplined autonomous loop for multi-step frontend site construction.

Overview

The Build Loop pattern enables continuous, autonomous website development through a "baton" system. Each iteration: 1. Reads the current task from a baton file (.stitch/next-prompt.md) 2. Generates a page using Stitch MCP tools 3. Integrates the page into the site structure 4. Writes the next task to the baton file for the next iteration

Prerequisites

Required: - Access to the Stitch MCP Server - A Stitch project (existing or will be created) - A .stitch/DESIGN.md file (generate one using the design-md skill if needed) - A .stitch/SITE.md file documenting the site vision and roadmap

Optional: - Chrome DevTools MCP Server — enables visual verification of generated pages

The Baton System

The .stitch/next-prompt.md file acts as a relay baton between iterations:

---
page: about
---
A page describing how jules.top tracking works.

**DESIGN SYSTEM (REQUIRED):**
[Copy from .stitch/DESIGN.md Section 6]

**Page Structure:**
1. Header with navigation
2. Explanation of tracking methodology
3. Footer with links

Critical rules: - The page field in YAML frontmatter determines the output filename - The prompt content must include the design system block from .stitch/DESIGN.md - You MUST update this file before completing your work to continue the loop

Execution Protocol

Step 1: Read the Baton

Parse .stitch/next-prompt.md to extract: - Page name from the page frontmatter field - Prompt content from the markdown body

Step 2: Consult Context Files

Before generating, read these files:

Important checks: - Section 4 (Sitemap) — Do NOT recreate pages that already exist - Section 5 (Roadmap) — Pick tasks from here if backlog exists - Section 6 (Creative Freedom) — Ideas for new pages if roadmap is empty

Step 3: Generate with Stitch

Use the Stitch MCP tools to generate the page:

1. Discover namespace: Run list_tools to find the Stitch MCP prefix
2. Get or create project:
3. If .stitch/metadata.json exists, use the projectId from it
4. Otherwise, call [prefix]:create_project, then call [prefix]:get_project to retrieve full project details, and save them to .stitch/metadata.json (see schema below)
5. After generating each screen, call [prefix]:get_project again and update the screens map in .stitch/metadata.json with each screen's full metadata (id, sourceScreen, dimensions, canvas position)
6. Generate screen: Call [prefix]:generate_screen_from_text with:
7. projectId: The project ID
8. prompt: The full prompt from the baton (including design system block)
9. deviceType: DESKTOP (or as specified)
10. Retrieve assets: Before downloading, check if .stitch/designs/{page}.html and .stitch/designs/{page}.png already exist:
11. If files exist: Ask the user whether to refresh the designs from the Stitch project or reuse the existing local files. Only re-download if the user confirms.
12. If files do not exist: Proceed with download:
    • htmlCode.downloadUrl — Download and save as .stitch/designs/{page}.html
    • screenshot.downloadUrl — Append =w{width} to the URL before downloading, where {width} is the width value from the screen metadata (Google CDN serves low-res thumbnails by default). Save as .stitch/designs/{page}.png

Step 4: Integrate into Site

1. Move generated HTML from .stitch/designs/{page}.html to site/public/{page}.html
2. Fix any asset paths to be relative to the public folder
3. Update navigation:
4. Find existing placeholder links (e.g., href="#") and wire them to the new page
5. Add the new page to the global navigation if appropriate
6. Ensure consistent headers/footers across all pages

Step 4.5: Visual Verification (Optional)

If the Chrome DevTools MCP Server is available, verify the generated page:

1. Check availability: Run list_tools to see if chrome* tools are present
2. Start dev server: Use Bash to start a local server (e.g., npx serve site/public)
3. Navigate to page: Call [chrome_prefix]:navigate to open http://localhost:3000/{page}.html
4. Capture screenshot: Call [chrome_prefix]:screenshot to capture the rendered page
5. **Visual compa