/stitch-loop

name: stitch-loop
description: Teaches agents to iteratively build websites using Stitch with an autonomous baton-passing loop pattern
allowed-tools:
  - "stitch*:*"
  - "chrome*:*"
  - "Read"
  - "Write"
  - "Bash"

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.

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:

| File | Purpose | |------|---------| | `.stitch/SITE.md` | Site vision, **Stitch Project ID**, existing pages (sitemap), roadmap | | `.stitch/DESIGN.md` | Required visual style for Stitch prompts |

**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**:

• If `.stitch/metadata.json` exists, use the `projectId` from it
• 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)
• 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)

3. **Generate screen**: Call `[prefix]:generate_screen_from_text` with:

• `projectId`: The project ID
• `prompt`: The full prompt from the baton (including design system block)
• `deviceType`: `DESKTOP` (or as specified)

4. **Retrieve assets**: Before downloading, check if `.stitch/designs/{page}.html` and `.stitch/designs/{page}.png` already exist:

• **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.
• **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:

• Find existing placeholder links (e.g., `href="#"`) and wire them to the new page
• Add the new page to the global navigation if appropriate

4. 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 comparison**: Compare against the Stitch screenshot (`.stitch/designs/{page}.png`) for fidelity 6. **Stop server**: Terminate the dev server process

> **Note:** This step is optional. If Chrome DevTools MCP is not installed, skip to Step 5.

Step 5: Update Site Documentation

Modify `.stitch/SITE.md`:

• Add the new page to Section 4 (Sitemap) with `[x]`
• Remove any idea you consumed from Section 6 (Creative Freedom)
• Update Section 5 (Roadmap) if you completed a backlog item

Step 6: Prepare the Next Baton (Critical)

**You MUST update `.stitch/next-prompt.md` before completing.** This keeps the loop alive.

1. **Decide the next page**:

• Check `.stitch/SITE.md` Section 5 (Roadmap) for pending items
• If empty, pick from Section 6 (Creative Freedom)
• Or invent something new that fits the site vision

2. **Write the baton** with proper YAML frontmatter:

---
page: achievements
---
A competitive achievements page showing developer badges and milestones.

**DESIGN SYSTEM (REQUIRED):**
[Copy the entire design system block from .stitch/DE