Post-conversion checklist

After HolyStitch writes the project to disk, your AI agent works through this checklist in order. The steps are documented in project-context.md inside every generated project so the agent can pick up where it left off — even in a new session.

Work through these steps in order. Each step builds on the previous. Running the build before fixing structural issues (step 1) generates misleading errors that slow you down.

Verify every component matches its source HTML

Before touching any generated file, open stitch-source/ and read each screen’s HTML from top to bottom.Why: HolyStitch is a deterministic regex-based compiler. It handles the mechanical transforms correctly, but three classes of issues require human or AI judgment:Unclosed tags — the most common issue. If a  comment marker sat inside a nested element, the component HTML was cut mid-element, leaving unclosed tags. Every opened tag must have a matching close tag. Reconstruct missing structure by reading the source HTML directly.Style strings — style="color:red" is invalid JSX. Every style= attribute must be converted to a style object with camelCase property names:

// Invalid JSX from raw HTML
style="background-image: url('x'); color: red"

// Correct JSX
style={{ backgroundImage: "url('x')", color: "red" }}

Multiple root elements — if a component returns two sibling elements with no wrapper, add a fragment:

return (
  <>
    <header>...</header>
    <nav>...</nav>
  </>
)

How to find the right source HTML: Look for the  comment marker in the source file. The block element immediately following that comment is the exact HTML the component should reproduce.

The stitch-source/ lookup table in project-context.md maps every route to its source HTML file so you can find the right file instantly.

Run the build and fix all TypeScript/JSX errors

Run the build and fix every error before proceeding to later steps.

Next.js
Vite

cd my-app
npm install
npm run build

cd my-app
npm install
npm run dev

Why: TypeScript and JSX errors reveal the structural issues that step 1’s visual inspection may have missed. A clean build is the foundation everything else depends on.When an error points to a component, open the corresponding stitch-source/*.html file as ground truth. Do not guess at the correct structure — read the original HTML.

Do not skip to later steps if the build fails. TypeScript errors in component files affect every page that imports them.

Wire up navigation routing

Stitch outputs every link as href="#" because it has no knowledge of multi-page routing. Replace those placeholders with real routes from the routing table in project-context.md.Why: Navigation components like TopNavBar and Footer are shared across all pages. Until their links point to real routes, the app is not navigable.

Next.js
Vite

Replace <a href="#"> with Next.js <Link>:

// Before
<a className="nav-link" href="#">Changelog</a>

// After
import Link from 'next/link';
<Link className="nav-link" href="/changelog">Changelog</Link>

For active-state styling, use usePathname() from next/navigation. Add 'use client' to any navigation component that reads the pathname:

'use client';
import { usePathname } from 'next/navigation';

export default function TopNavBar(_props: TopNavBarProps) {
  const pathname = usePathname();
  return (
    <nav>
      <Link
        href="/changelog"
        className={pathname === '/changelog' ? 'font-bold text-primary' : 'text-gray-600'}
      >
        Changelog
      </Link>
    </nav>
  );
}

Replace href="#" with hash routes:

// Before
<a className="nav-link" href="#">Changelog</a>

// After
<a className="nav-link" href="/#/changelog">Changelog</a>

For active-state styling, accept an activeRoute prop and compare it against each link’s route to apply the active classes from the source HTML:

interface TopNavBarProps {
  activeRoute?: string;
}
export default function TopNavBar({ activeRoute }: TopNavBarProps) {
  return (
    <nav>
      <a
        href="/#/changelog"
        className={activeRoute === '/changelog' ? 'font-bold text-primary' : 'text-gray-600'}
      >
        Changelog
      </a>
    </nav>
  );
}

Links with no matching internal route (social links, external URLs) should use their real href or remain as href="#" with a // TODO comment.

Normalize inline font declarations

Stitch emits font families as Tailwind arbitrary values like font-['Inter'] or font-['JetBrains_Mono']. Replace these with the semantic aliases already defined in tailwind.config.js.Why: Arbitrary font classes bypass your Tailwind theme config and make future re-theming harder. The extracted theme already has named aliases — use them.How to do this:

Open tailwind.config.js and read the fontFamily keys in theme.extend.
Search every .tsx / .jsx file in components/ for font-['...'] patterns.
Replace each inline font class with the matching semantic alias:

// Before — arbitrary value from Stitch output
<p className="font-['Inter'] text-base">Body copy</p>

// After — semantic alias from tailwind.config.js
<p className="font-body text-base">Body copy</p>

If multiple aliases map to the same font family, pick the alias that best describes the element’s role:

Element	Alias to use
Headings (`h1`–`h3`)	`font-headline`
Body copy	`font-body`
Labels, captions	`font-label`
Code blocks	`font-mono`

Run the build after replacing to confirm no class names were broken.

Verify each page renders correctly in a browser

Start the dev server and open each route in a browser. Compare each page visually against its source HTML rendered directly in a browser.Why: The build passing does not guarantee visual correctness. Layout, spacing, color, and content issues only surface in the browser.For each route listed in project-context.md, check:

Layout and spacing match the source HTML
Colors match (consult tailwind.config.js for token values)
All text content is verbatim — headings, labels, copy
Images render (or placeholder URLs are visible — addressed in step 7)
Navigation links are wired up from step 3

Fix discrepancies by consulting stitch-source/ — not by guessing at class names.

Review the Tailwind theme config

Open tailwind.config.js and verify the extracted theme renders correctly.Why: HolyStitch extracts the Tailwind theme directly from the Stitch HTML, but multi-screen projects can produce token conflicts if different screens define the same color token with different values. These conflicts are flagged in project-context.md under Structural Warnings.If a conflict was detected, open each conflicting screen’s source HTML in stitch-source/ and decide which value is correct for the shared theme.

If project-context.md notes that no Tailwind config was found in the HTML, the default Tailwind theme is used. You will need to add your custom colors and fonts manually.

Replace placeholder images

All src and backgroundImage URLs pointing to lh3.googleusercontent.com are temporary Stitch preview links. They may expire or be rate-limited.Why: Stitch serves image previews from its own CDN. These URLs are not suitable for production and should be replaced with assets you control.Replace placeholder URLs with:

Images in your /public directory: src="/images/hero.png"
A CDN of your choice
Imported local assets (Vite): import heroImg from './assets/hero.png'

Search for lh3.googleusercontent.com across all component files to find every occurrence:

grep -r "lh3.googleusercontent.com" components/

Add 'use client' where needed

Any Next.js component that uses useState, useEffect, event handlers (onClick, onChange, etc.), or browser APIs requires 'use client' as its first line.Why: Next.js App Router components are Server Components by default. Client-only APIs are not available in Server Components and will cause a runtime error.HolyStitch automatically adds 'use client' to components where it detects event handlers during conversion. However, verify manually — the converter uses a heuristic and may miss some cases, particularly when hooks are added during post-conversion edits.

'use client';

import React, { useState } from 'react';

interface AccordionProps {}

export default function Accordion(_props: AccordionProps) {
  const [open, setOpen] = useState(false);
  return (
    <div onClick={() => setOpen(!open)}>...</div>
  );
}

Vite projects do not need 'use client'. All components in a Vite project can use hooks and event handlers freely.

Add typed component props (optional polish)

All generated components have empty interface ComponentNameProps {} definitions. Once the build passes and pages render correctly, add typed props for configurable values.Why: The converter preserves all content as static JSX. Adding props makes components reusable and documents the configurable surface area of each component.Good candidates for props, flagged as inline comments in each component file:

Heading text: title: string
Image URLs: imageSrc: string
Link targets: href: string
Variant flags: variant: 'primary' | 'secondary'

interface HeroSectionProps {
  title: string;
  // Potential prop: imageSrc — replace hardcoded Stitch image URLs
  imageSrc: string;
}

export default function HeroSection({ title, imageSrc }: HeroSectionProps) {
  return (
    <section>
      <h1>{title}</h1>
      <img src={imageSrc} alt="" />
    </section>
  );
}

This step is optional polish. A complete, pixel-accurate project with static content is a valid outcome — you can add props incrementally as you integrate the components into your application.

Get Started

Configuration

How It Works

Output

Contributing

Post-conversion checklist

Build docs developers (and LLMs) love

Get Started

Configuration

How It Works

Output

Contributing

Documentation Index

Build docs developers (and LLMs) love