Build websites autonomously through iterative task loops

Stitch Build Loop organizes iterative website construction around a baton file. Each pass reads the next page task, generates a screen through Stitch, integrates the resulting HTML into the site, records completed work, and writes instructions for the following pass. The pattern supports continuation across runs without relying on remembered conversation details.

The baton is .stitch/next-prompt.md. Its YAML page field determines the output filename, and its body includes the required design-system block. Before generation, the workflow reads .stitch/SITE.md for the site vision, project identifier, sitemap, pending work, and permissible creative direction. It also reads .stitch/DESIGN.md for the visual language. Existing sitemap entries prevent duplicate page creation.

Generation discovers the Stitch tool namespace and reuses persisted project metadata when available. If a project is created, the workflow retrieves its full details and stores them. After generating a screen, it refreshes the screen map with identifiers, resource paths, dimensions, and canvas positions so later edits can reference the same design.

Use it for a multi-step website built with Stitch where each pass must complete a page and prepare the next task. It is suited to repeated manual runs, review between iterations, or an external orchestration layer.

Required inputs are Stitch MCP access, a project or permission to create one, a design document, and a site document. Chrome DevTools MCP is optional for visual comparison. Missing requirements or permissions need clarification, and generated pages still require environment-specific validation.

If a page's local HTML and screenshot already exist, the workflow asks whether to reuse them or refresh them from Stitch. It does not silently re-download over existing design assets. Finishing a page without updating the baton breaks the continuation pattern.

Inputs include the baton prompt, page name, design block, site context, device target, and persisted Stitch identifiers. Outputs include staged HTML and screenshots, integrated public pages, corrected relative asset paths, wired navigation, updated site documentation, refreshed metadata, and the next baton.

Downloads use screen metadata to preserve screenshot resolution; the image URL is adjusted to the recorded screen width. HTML moves into site/public under the page name. Placeholder links are connected to real destinations, and headers and footers remain consistent across pages.

Optional browser verification starts a local server, opens the generated page, captures its rendering, compares it with the Stitch screenshot, and stops the server. Start the local preview server with:

npx serve site/public

After integration, the sitemap marks the new page complete and consumed ideas are removed. The next task comes from pending work, available creative ideas, or a new page that fits the site vision. It receives valid frontmatter and the complete design-system block.

Stitch MCP handles projects and screen generation. The metadata file retains project name, title, visibility, device type, theme tokens, screen resources, and user role. Supported device targets include mobile, desktop, and tablet.

The design-md skill can derive the initial design document from an existing screen. Chrome DevTools MCP supplies optional visual verification. Orchestration examples include GitHub Actions reacting to baton changes, developer review, chained runs, and repeated manual execution. The loop does not depend on a particular trigger mechanism.

Troubleshooting checks missing design blocks, outdated style context, invalid baton frontmatter, unpersisted identifiers, and incorrect relative navigation paths.

It suits people building a website page by page with Stitch who need consistent visual context and clear continuation instructions. It helps keep generated designs, integrated pages, and the record of remaining work aligned.