How to Create Multi-Page Websites from a Single Prompt with stitch-loop

The stitch-loop skill implements a stateless Baton System that coordinates autonomous agents to iteratively generate, integrate, and publish pages, enabling complete multi-page websites to emerge from sequential single prompts without requiring external state stores.

The stitch-loop skill in the google-labs-code/stitch-skills repository transforms isolated text prompts into cohesive multi-page websites through a disciplined handoff protocol. By treating a markdown file as a mutable baton, the system allows any agent—human, CI pipeline, or automated bot—to participate in an iterative generation loop that maintains strict design consistency across all pages.

Understanding the Baton System Architecture

The Baton System is the core coordination mechanism that makes autonomous multi-page generation possible. Rather than maintaining complex state in memory or external databases, stitch-loop persists coordination data directly in the repository using a specific markdown contract.

The Role of next-prompt.md

The .stitch/next-prompt.md file acts as the communication channel between iterations. This file contains YAML front-matter specifying the target page: identifier and a markdown body describing the content requirements and design system references.

According to the schema defined in plugins/stitch-utilities/skills/stitch-loop/resources/baton-schema.md, the baton must include:

• YAML front-matter: The page: key (e.g., page: about) determines the output filename
• Content instructions: The markdown body describes the specific page content
• Design system injection: A mandatory reference to the design system block that ensures visual consistency

Context Persistence Through SITE.md and DESIGN.md

Two canonical files provide the agent with persistent site-wide context:

• .stitch/SITE.md: Contains the site vision, current sitemap (Section 4), roadmap (Section 5), and creative freedom items (Section 6)
• .stitch/DESIGN.md: Stores the complete design system block that gets injected into every generation prompt

The agent reads these files at the start of each iteration to understand the broader architecture and visual constraints before generating new content.

The 7-Stage Generation Workflow

Each execution of the stitch-loop skill processes through seven distinct stages, as implemented in plugins/stitch-utilities/skills/stitch-loop/SKILL.md:

Stage 1: Read the Baton

The agent parses .stitch/next-prompt.md, extracting the page: value from YAML front-matter and the prompt instructions from the markdown body.

Stage 2: Load Context

The system reads .stitch/SITE.md for site vision and sitemap status, and .stitch/DESIGN.md for the design-system block that ensures visual consistency across pages.

Stage 3: Generate with Stitch

Using Stitch MCP tools (create_project, generate_screen_from_text), the agent generates the screen. The full prompt includes:

• The original instructions from the baton
• The complete design system block copied from .stitch/DESIGN.md Section 6

Results are saved to .stitch/designs/{page}.html and .stitch/designs/{page}.png.

Stage 4: Integrate

The generated HTML moves from .stitch/designs/ to site/public/{page}.html. The integration logic calls fix_asset_paths() to correct relative URLs and update_navigation() to replace placeholder links like href="#" with actual site navigation.

Stage 5: Optional Visual Verification

If a Chrome DevTools MCP server is available, the agent can launch a local dev server, navigate to the new page, capture a screenshot, and compare it against the Stitch-generated reference image.

Stage 6: Update Site Documentation

The agent modifies .stitch/SITE.md to:

• Mark the completed page in the Sitemap section (e.g., changing - [ ] about.html to - [x] about.html)
• Remove consumed items from the "Creative Freedom" section
• Update the Roadmap if a backlog item was fulfilled

Stage 7: Write the Next Baton

This step is mandatory—without it, the loop halts. The agent composes a fresh .stitch/next-prompt.md targeting the next page in the roadmap, embedding the design system block and new content instructions.

Practical Implementation Guide

Creating the Initial Baton

Begin by crafting the seed file that starts the loop:

---
page: index
---
A landing page for the product with hero section and feature grid.

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

**Page Structure:**
1. Navigation header with logo
2. Hero section with CTA
3. Feature grid (3 columns)
4. Footer with links

Configuring SITE.md

Create .stitch/SITE.md to establish the site structure:

# Site Vision

Modern SaaS Analytics Dashboard

## 4. Sitemap

- [ ] index.html
- [ ] about.html
- [ ] pricing.html

## 5. Roadmap

- Create landing page
- Add about section
- Build pricing table

## 6. Creative Freedom

- Use gradient backgrounds
- Implement dark mode toggle

The Integration Logic

The actual implementation follows this pattern, as defined in the skill's execution flow:

# 1. Read baton

baton = read_file('.stitch/next-prompt.md')
page = yaml_frontmatter(baton)['page']
prompt = markdown_body(baton)

# 2. Load context

design = read_file('.stitch/DESIGN.md')
site = read_file('.stitch/SITE.md')

# 3. Prepare generation prompt

full_prompt = f"{prompt}\n\n**DESIGN SYSTEM (REQUIRED):**\n{design}"

# 4. Stitch MCP calls

project_id = get_or_create_project()
screen = generate_screen_from_text(project_id, full_prompt, device='DESKTOP')

# 5. Download assets

download(screen.htmlUrl, f'.stitch/designs/{page}.html')
download(screen.screenshotUrl + f"=w{screen.width}", f'.stitch/designs/{page}.png')

# 6. Integrate into site

move(f'.stitch/designs/{page}.html', f'site/public/{page}.html')
fix_asset_paths(f'site/public/{page}.html')
update_navigation(f'site/public/{page}.html')

# 7. Update documentation

site = mark_page_completed(site, page)
site = pop_next_roadmap_item(site)
write_file('.stitch/SITE.md', site)

# 8. Write next baton (mandatory for loop continuation)

next_baton = """---
page: about
---
Company history and team section...

**DESIGN SYSTEM (REQUIRED):**
""" + design
write_file('.stitch/next-prompt.md', next_baton)

Metadata Persistence

The system maintains project continuity through .stitch/metadata.json:

{
  "projectId": "6139132077804554844",
  "screens": {
    "index": { "id": "screen_abc123", "width": 390, "height": 1249 },
    "about": { "id": "screen_def456", "width": 390, "height": 1159 }
  }
}

This file stores Stitch project IDs and screen dimensions, enabling later edits without recreating projects.

Automation with CI/CD

Trigger the loop automatically using GitHub Actions by monitoring the baton file:

name: Stitch Loop
on:
  push:
    paths:
      - '.stitch/next-prompt.md'
jobs:
  run-loop:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run stitch-loop skill
        run: |
          stitch-skill run stitch-loop

This configuration executes the skill whenever the baton file changes, enabling fully automated site expansion.

Summary

• Baton-driven coordination: The .stitch/next-prompt.md file provides a version-controlled handoff mechanism between generation iterations
• Design consistency: Embedding the full design system block from .stitch/DESIGN.md into every prompt prevents visual drift across pages
• Mandatory loop continuation: Writing the next baton is required—without this step, the autonomous workflow halts
• State persistence: Project metadata lives in .stitch/metadata.json while site architecture is documented in .stitch/SITE.md
• Integration hooks: The skill automatically handles asset path correction and navigation wiring when moving files from .stitch/designs/ to site/public/

Frequently Asked Questions

What happens if the next-prompt.md file is missing?

The stitch-loop skill requires the baton file to operate. If .stitch/next-prompt.md is absent, the agent cannot determine which page to generate or what content to create, causing the loop to halt immediately. The workflow treats this as a termination signal rather than an error.

How does stitch-loop maintain consistent styling across different pages?

Every prompt includes the complete design system block copied from .stitch/DESIGN.md Section 6. This injection ensures that generate_screen_from_text receives identical visual constraints for each page, preventing the stylistic drift that typically occurs in multi-step generation tasks.

Can I use stitch-loop without a Chrome DevTools MCP server?

Yes. Stage 5 (Visual Verification) is entirely optional. The skill functions completely without the Chrome DevTools MCP server, skipping the screenshot comparison step and proceeding directly to integration and documentation updates.

Where does stitch-loop store the generated HTML before integration?

The skill temporarily saves outputs to .stitch/designs/{page}.html and .stitch/designs/{page}.png before moving them to site/public/{page}.html during the integration stage. This two-phase approach allows for optional visual verification and serves as a buffer between the generation environment and the production site directory.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}