$npx -y skills add google-labs-code/stitch-skills --skill stitch-loopstitch-loop is an agent skill published from google-labs-code/stitch-skills, installable through the skills CLI.
| 1 | # Stitch Build Loop |
| 2 | |
| 3 | 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. |
| 4 | |
| 5 | ## Overview |
| 6 | |
| 7 | The Build Loop pattern enables continuous, autonomous website development through a "baton" system. Each iteration: |
| 8 | 1. Reads the current task from a baton file (`.stitch/next-prompt.md`) |
| 9 | 2. Generates a page using Stitch MCP tools |
| 10 | 3. Integrates the page into the site structure |
| 11 | 4. Writes the next task to the baton file for the next iteration |
| 12 | |
| 13 | ## Prerequisites |
| 14 | |
| 15 | **Required:** |
| 16 | - Access to the Stitch MCP Server |
| 17 | - A Stitch project (existing or will be created) |
| 18 | - A `.stitch/DESIGN.md` file (generate one using the `design-md` skill if needed) |
| 19 | - A `.stitch/SITE.md` file documenting the site vision and roadmap |
| 20 | |
| 21 | **Optional:** |
| 22 | - Chrome DevTools MCP Server — enables visual verification of generated pages |
| 23 | |
| 24 | ## The Baton System |
| 25 | |
| 26 | The `.stitch/next-prompt.md` file acts as a relay baton between iterations: |
| 27 | |
| 28 | ```markdown |
| 29 | --- |
| 30 | page: about |
| 31 | --- |
| 32 | A page describing how jules.top tracking works. |
| 33 | |
| 34 | **DESIGN SYSTEM (REQUIRED):** |
| 35 | [Copy from .stitch/DESIGN.md Section 6] |
| 36 | |
| 37 | **Page Structure:** |
| 38 | 1. Header with navigation |
| 39 | 2. Explanation of tracking methodology |
| 40 | 3. Footer with links |
| 41 | ``` |
| 42 | |
| 43 | **Critical rules:** |
| 44 | - The `page` field in YAML frontmatter determines the output filename |
| 45 | - The prompt content must include the design system block from `.stitch/DESIGN.md` |
| 46 | - You MUST update this file before completing your work to continue the loop |
| 47 | |
| 48 | ## Execution Protocol |
| 49 | |
| 50 | ### Step 1: Read the Baton |
| 51 | |
| 52 | Parse `.stitch/next-prompt.md` to extract: |
| 53 | - **Page name** from the `page` frontmatter field |
| 54 | - **Prompt content** from the markdown body |
| 55 | |
| 56 | ### Step 2: Consult Context Files |
| 57 | |
| 58 | Before generating, read these files: |
| 59 | |
| 60 | | File | Purpose | |
| 61 | |------|---------| |
| 62 | | `.stitch/SITE.md` | Site vision, **Stitch Project ID**, existing pages (sitemap), roadmap | |
| 63 | | `.stitch/DESIGN.md` | Required visual style for Stitch prompts | |
| 64 | |
| 65 | **Important checks:** |
| 66 | - Section 4 (Sitemap) — Do NOT recreate pages that already exist |
| 67 | - Section 5 (Roadmap) — Pick tasks from here if backlog exists |
| 68 | - Section 6 (Creative Freedom) — Ideas for new pages if roadmap is empty |
| 69 | |
| 70 | ### Step 3: Generate with Stitch |
| 71 | |
| 72 | Use the Stitch MCP tools to generate the page: |
| 73 | |
| 74 | 1. **Discover namespace**: Run `list_tools` to find the Stitch MCP prefix |
| 75 | 2. **Get or create project**: |
| 76 | - If `.stitch/metadata.json` exists, use the `projectId` from it |
| 77 | - 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) |
| 78 | - 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) |
| 79 | 3. **Generate screen**: Call `[prefix]:generate_screen_from_text` with: |
| 80 | - `projectId`: The project ID |
| 81 | - `prompt`: The full prompt from the baton (including design system block) |
| 82 | - `deviceType`: `DESKTOP` (or as specified) |
| 83 | 4. **Retrieve assets**: Before downloading, check if `.stitch/designs/{page}.html` and `.stitch/designs/{page}.png` already exist: |
| 84 | - **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. |
| 85 | - **If files do not exist**: Proceed with download: |
| 86 | - `htmlCode.downloadUrl` — Download and save as `.stitch/designs/{page}.html` |
| 87 | - `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` |
| 88 | |
| 89 | ### Step 4: Integrate into Site |
| 90 | |
| 91 | 1. Move generated HTML from `.stitch/designs/{page}.html` to `site/public/{page}.html` |
| 92 | 2. Fix any asset paths to be relative to the public folder |
| 93 | 3. Update navigation: |
| 94 | - Find existing placeholder links (e.g., `href="#"`) and wire them to the new page |
| 95 | - Add the new page to the global navigation if appropriate |
| 96 | 4. Ensure consistent headers/footers across all pages |
| 97 | |
| 98 | ### Step 4.5: Visual Verification (Optional) |
| 99 | |
| 100 | If the **Chrome DevTools MCP Server** is available, verify the generated page: |
| 101 | |
| 102 | 1. **Check availability**: Run `list_tools` to see if `chrome*` tools are present |
| 103 | 2. **Start dev server**: Use Bash to start a local server (e.g., `npx serve site/public`) |
| 104 | 3. **Navigate to page**: Call `[chrome_prefix]:navigate` to open `http://localhost:3000/{page}.html` |
| 105 | 4. **Capture screenshot**: Call `[chrome_prefix]:screenshot` to capture the rendered page |
| 106 | 5. **Visual comparison**: Compare against the Stitch screenshot (`.stitch/designs/{page}.png`) |