# How stitch::stitch-loop Generates Multi-Page Websites From a Single Prompt

> Discover how stitch::stitch-loop creates multi-page websites from one prompt. Learn about its baton-passing workflow, persistent context, and iterative page generation.

- Repository: [Google Labs Code/stitch-skills](https://github.com/google-labs-code/stitch-skills)
- Tags: how-to-guide
- Published: 2026-07-12

---

**stitch::stitch-loop uses a baton-passing workflow driven by the [`.stitch/next-prompt.md`](https://github.com/google-labs-code/stitch-skills/blob/main/.stitch/next-prompt.md) file to iteratively generate pages, allowing a single initial prompt to expand into a complete multi-page website while preserving design consistency through persistent context files.**

The stitch::stitch-loop skill in the `google-labs-code/stitch-skills` repository implements an autonomous orchestration pattern that transforms one high-level prompt into a full-featured website. Unlike traditional static site generators that require manual configuration for each page, this system leverages a "baton" file to maintain state, context, and roadmap across iterations, enabling true multi-page generation from minimal input.

## The Baton System Architecture

At the heart of stitch::stitch-loop lies the **baton file** ([`.stitch/next-prompt.md`](https://github.com/google-labs-code/stitch-skills/blob/main/.stitch/next-prompt.md)), a YAML-fronted markdown document that acts as the single source of truth for each iteration. This file contains the page identifier in its front matter and the generation prompt in its body, effectively passing control from one loop iteration to the next.

According to the source documentation in [`plugins/stitch-utilities/skills/stitch-loop/SKILL.md`](https://github.com/google-labs-code/stitch-skills/blob/main/plugins/stitch-utilities/skills/stitch-loop/SKILL.md) (lines 37-45), the baton structure requires:

- **YAML front matter**: Contains the `page` key identifying the current page (e.g., `page: index`)
- **Markdown body**: Contains the specific generation prompt, including a mandatory **DESIGN SYSTEM** block copied from [`.stitch/DESIGN.md`](https://github.com/google-labs-code/stitch-skills/blob/main/.stitch/DESIGN.md)

The baton pattern ensures that each iteration knows exactly what to build next while maintaining a persistent thread of the overall site vision.

## The Seven-Step Execution Loop

The stitch::stitch-loop operates through a precise seven-step workflow documented in [`SKILL.md`](https://github.com/google-labs-code/stitch-skills/blob/main/SKILL.md). Each cycle reads the current state, generates one page, and prepares the next iteration.

### Step 1: Read the Baton

The loop begins by parsing [`.stitch/next-prompt.md`](https://github.com/google-labs-code/stitch-skills/blob/main/.stitch/next-prompt.md) to extract the YAML front matter and prompt body. This step identifies which page to generate and what specific content or layout to create.

### Step 2: Gather Context

Before generation, the system loads two critical context files:
- **[`.stitch/SITE.md`](https://github.com/google-labs-code/stitch-skills/blob/main/.stitch/SITE.md)**: Contains the site vision, sitemap, and roadmap
- **[`.stitch/DESIGN.md`](https://github.com/google-labs-code/stitch-skills/blob/main/.stitch/DESIGN.md)**: Houses the immutable design system, including color palettes, typography, and component specifications

As implemented in [`SKILL.md`](https://github.com/google-labs-code/stitch-skills/blob/main/SKILL.md) (lines 69-75), these files ensure every generated page adheres to the established visual language and site architecture.

### Step 3: Generate the Page

Using the Stitch MCP API, the system calls tools such as `create_project` and `generate_screen_from_text` with a composite prompt that includes both the page-specific instructions and the design system block. This occurs in [`SKILL.md`](https://github.com/google-labs-code/stitch-skills/blob/main/SKILL.md) (lines 85-94), where the prompt explicitly injects the design system to ensure visual consistency.

### Step 4: Download Assets

Upon successful generation, the loop retrieves the generated HTML and screenshot from the Stitch MCP API. These assets are stored temporarily under `.stitch/designs/{page}.html` and `.stitch/designs/{page}.png` (see [`SKILL.md`](https://github.com/google-labs-code/stitch-skills/blob/main/SKILL.md), lines 95-99).

### Step 5: Integrate Into the Site

The generated HTML moves from the temporary designs folder to the production site structure at `site/public/{page}.html`. This step, detailed in [`SKILL.md`](https://github.com/google-labs-code/stitch-skills/blob/main/SKILL.md) (lines 102-107), also handles asset path correction and navigation link wiring, ensuring the new page connects properly to the existing site structure.

### Step 6: Update Documentation

The system amends [`.stitch/SITE.md`](https://github.com/google-labs-code/stitch-skills/blob/main/.stitch/SITE.md) to reflect the newly created page, updating the sitemap and roadmap to mark items as complete. This documentation step (lines 122-128 in [`SKILL.md`](https://github.com/google-labs-code/stitch-skills/blob/main/SKILL.md)) maintains an accurate record of site progress.

### Step 7: Write the Next Baton

Finally, the loop creates a new [`.stitch/next-prompt.md`](https://github.com/google-labs-code/stitch-skills/blob/main/.stitch/next-prompt.md) file describing the next page to generate. As documented in [`SKILL.md`](https://github.com/google-labs-code/stitch-skills/blob/main/SKILL.md) (lines 29-52), this step consults the site roadmap and "Creative Freedom" section to determine what comes next, effectively passing the baton to the subsequent iteration.

## Why a Single Prompt Works

The stitch::stitch-loop achieves multi-page generation from a single initial prompt through three architectural principles:

- **Immutable Design System**: The [`.stitch/DESIGN.md`](https://github.com/google-labs-code/stitch-skills/blob/main/.stitch/DESIGN.md) file, populated from [`plugins/stitch-utilities/skills/stitch-loop/resources/site-template.md`](https://github.com/google-labs-code/stitch-skills/blob/main/plugins/stitch-utilities/skills/stitch-loop/resources/site-template.md), remains constant across iterations. By injecting this file into every generation prompt, the system ensures visual consistency without requiring repetitive design instructions.

- **Persistent State**: The [`.stitch/metadata.json`](https://github.com/google-labs-code/stitch-skills/blob/main/.stitch/metadata.json) file persists Stitch project and screen IDs across iterations, while [`.stitch/SITE.md`](https://github.com/google-labs-code/stitch-skills/blob/main/.stitch/SITE.md) tracks the evolving sitemap. This eliminates the need to re-specify site context for each page.

- **Autonomous Roadmap Following**: The initial baton seeds the site vision, but subsequent iterations read from the updated [`SITE.md`](https://github.com/google-labs-code/stitch-skills/blob/main/SITE.md) backlog or "Creative Freedom" sections to determine what to build next, allowing the site to grow organically beyond the initial prompt scope.

## Implementation Code Examples

The following pseudo-code illustrates the core loop logic as implemented in the skill:

```python

# Step 1: Read the baton

baton = yaml.safe_load(open('.stitch/next-prompt.md'))
page_name = baton['page']
prompt_body = read_body('.stitch/next-prompt.md')

# Step 2: Load context

site = markdown.load('.stitch/SITE.md')
design = markdown.load('.stitch/DESIGN.md')
full_prompt = f"{prompt_body}\n\n{design}"

# Step 3: Call Stitch MCP

project_id = get_or_create_project()
screen = stitch.generate_screen(project_id, full_prompt, device='DESKTOP')

# Step 4: Download assets

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

# Step 5: Integrate

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

# Step 6: Update SITE.md

site.sitemap.append(f"* [x] `{page_name}.html` – {baton.get('description','')}")
markdown.save('.stitch/SITE.md', site)

# Step 7: Write next baton

next_page = decide_next_page(site)
next_baton = f"""---
page: {next_page}
---
<new prompt …>

**DESIGN SYSTEM (REQUIRED):**
{design}
"""
open('.stitch/next-prompt.md','w').write(next_baton)

```

The `decide_next_page` function prioritizes the site backlog before falling back to creative freedom ideas:

```python
def decide_next_page(site):
    # Prefer backlog items

    for item in site.backlog:
        if not item.completed:
            return item.slug
    # Fallback to creative freedom

    for idea in site.creative_freedom:
        if not idea.consumed:
            return idea.slug
    return f"page-{int(time.time())}"

```

## Summary

- **stitch::stitch-loop** uses a baton-passing architecture centered on [`.stitch/next-prompt.md`](https://github.com/google-labs-code/stitch-skills/blob/main/.stitch/next-prompt.md) to orchestrate multi-page generation.
- The seven-step workflow (Read → Context → Generate → Download → Integrate → Update → Write) creates a self-reinforcing loop that builds sites incrementally.
- **Immutable design systems** in [`.stitch/DESIGN.md`](https://github.com/google-labs-code/stitch-skills/blob/main/.stitch/DESIGN.md) ensure visual consistency across all generated pages without repeated prompting.
- The system relies on **MCP tools** (`create_project`, `generate_screen_from_text`) and maintains state through [`.stitch/SITE.md`](https://github.com/google-labs-code/stitch-skills/blob/main/.stitch/SITE.md) and [`.stitch/metadata.json`](https://github.com/google-labs-code/stitch-skills/blob/main/.stitch/metadata.json).
- This architecture allows a single initial prompt to spawn complete multi-page websites through autonomous iteration.

## Frequently Asked Questions

### How does stitch::stitch-loop maintain design consistency across multiple pages?

The system maintains consistency by injecting the **[`.stitch/DESIGN.md`](https://github.com/google-labs-code/stitch-skills/blob/main/.stitch/DESIGN.md)** file into every generation prompt. This file contains the site-wide design system including colors, typography, and component specifications. Because the baton file ([`next-prompt.md`](https://github.com/google-labs-code/stitch-skills/blob/main/next-prompt.md)) requires a "DESIGN SYSTEM (REQUIRED)" block copied from this file, every page generation receives identical design constraints, ensuring a unified visual language across the entire site.

### What triggers the stitch::stitch-loop to stop generating pages?

The loop terminates when the site backlog and creative freedom sections in **[`.stitch/SITE.md`](https://github.com/google-labs-code/stitch-skills/blob/main/.stitch/SITE.md)** contain no remaining unconsumed items. According to the `decide_next_page` logic in [`SKILL.md`](https://github.com/google-labs-code/stitch-skills/blob/main/SKILL.md), when all roadmap items are complete and all creative ideas are exhausted, the system has no further baton to write, effectively ending the autonomous generation cycle.

### Can stitch::stitch-loop integrate with existing CI/CD pipelines?

Yes, the loop is orchestration-agnostic. Because each iteration depends solely on the state of files in the `.stitch/` directory (particularly [`.stitch/next-prompt.md`](https://github.com/google-labs-code/stitch-skills/blob/main/.stitch/next-prompt.md)), the workflow can be triggered by CI/CD systems, human reviewers, or upstream agent chains. The file-based baton system makes it compatible with any automation platform that can read and write repository files.

### What is the role of [`.stitch/metadata.json`](https://github.com/google-labs-code/stitch-skills/blob/main/.stitch/metadata.json) in the generation process?

The **[`.stitch/metadata.json`](https://github.com/google-labs-code/stitch-skills/blob/main/.stitch/metadata.json)** file persists Stitch project and screen IDs across loop iterations. This state persistence allows the system to reference existing projects when calling MCP tools like `generate_screen_from_text`, avoiding redundant project creation and maintaining continuity between the Stitch MCP API and the local file system.