Rebuilding a Yoga Retreat website with Claude — process notes:

This is a little long, but I hope it serves.

After 3.1 where Jake showed how to build a site with Claude, I took it one step above the build I did while learning.

Below is the process Claude and I went through. Claude did all based on the lesson, though the site is far more complex, so we built pages in sections.

I'm a yoga teacher, not a developer. Over the past two days I rebuilt my retreat center website end-to-end using Claude Chat as the architect and Claude Code as the worker. Sharing the process because the patterns that emerged were unexpected and probably useful to anyone doing similar work.

Before: khanomyoga.com — a Kajabi template, generic, full of invented specifics and dated styling.

After: khanom-yoga.netlify.app — Astro + Tailwind, real photos, voice-aligned copy, layered JSON-LD, four-bucket inquiry forms, decision-complete brand reference.

15 routes, ~17 commits, 9 numbered build sessions plus 4 cleanup passes. Source on GitHub (private).

The architect / worker split

The single most important structural choice was separating planning from execution into two different Claude contexts.

Architect (Claude Chat in a project with a custom system prompt): writes briefing docs, PRD, per-session prompts, brand reference, cross-project bridges. Does not write production code.
Worker (Claude Code in the actual repo): scaffolds, edits, builds, commits, pushes. Reads the architect's prompts and the project's CLAUDE.md.

The two never share a context window. The architect's outputs travel through the filesystem as markdown files the worker can read.

The architect's job is to spend thinking before spending tokens — analyze, scope, write the prompt with explicit boundaries, surface the load-bearing decisions for owner approval. The worker's job is to execute that prompt without scope drift.

The session pattern

Every build session followed the same shape:

Architect drafts a numbered prompt — 05-session-2-prompt.md, 06-session-3-prompt.md, etc. Each prompt has: scope, hard rules, what NOT to build, three questions to ask before coding, after-session deliverables.
Owner pastes the prompt block into Claude Code.
Worker asks the three questions — usually variations on confirming defaults the architect proposed, but worker is empowered to push back.
Owner approves or amends in chat.
Worker builds, commits, pushes — single commit per session with a structured message.
Worker hands back a summary with commit hash, what landed, what's stubbed, what surprised them.
Architect reviews the summary, lines up the next session.

The numbered files in the repo root form a complete audit trail. Anyone reading them in order can reconstruct every decision.

The fabrication problem:

The recurring failure mode of LLMs in content work is plausible-sounding fiction. Across the first three sessions, the worker invented:

A fictional faculty member ("Dr. Anya Wirat") to demonstrate a card layout
A capacity number ("12-guest cap") that was never specified
An entire fake retreat ("Surf & Yoga Week")
A tagline ("the coast Thailand forgot to market")
Refund-policy day counts
An incorrect ocean ("Andaman" — Khanom is on the Gulf of Thailand)

Each surfaced only after the fact. The fix that finally worked was a discipline pattern baked into every prompt thereafter:

If a section needs a specific you don't have:

Use clearly-marked placeholder copy ([Placeholder: …])
Add an HTML comment in the rendered output ()
Flag every placeholder in your final summary

Plausible-sounding fiction is worse than visible placeholders. Visitors trust visible "TODO" markers more than a confident lie they later discover.

After that framing landed, the worker started self-policing — flagging fabrications it found in earlier-session code that I'd missed, surfacing them for explicit owner decision instead of silently fixing or fabricating. That's the moment the discipline became real.

Two cleanup sessions (4.5 and 4.5b) replaced every fabricated specific with placeholders. By session 7's voice-alignment pass, the worker was rejecting its own previous invention reflexively.

Cross-project bridges

Khanom Yoga is owned by GabeYoga (my teacher brand), which lives in a different Claude project sandbox. Sandboxes don't share memory — each Claude session only sees its own working directory. So awareness has to be documented, not connected.

What worked: a RELATED_PROJECTS.md in each side's project root pointing at the other, with the brand relationship spelled out. When the brand-alignment pass arrived, I had GabeYoga's Claude generate a single BRAND.md export — voice rules, key phrases, founder bio long-form, design rules — that I hand-carried into the Khanom Yoga repo. From there, voice editing happened against that file as authoritative reference.

Two interesting sub-decisions:

Khanom Yoga is a venue sub-brand allowed visual distinctiveness (Fraunces + Inter + bone) while inheriting GabeYoga's voice in full. Locked in §6 of BRAND.md.
A second audience surfaced mid-build: independent yoga teachers who want to host their own retreats at Khanom. Existing offering, not on a single page of the prior build. Got its own page (/host-your-retreat) plus its own Netlify form bucket.

The X.5 cleanup pattern

Numbered sessions were big building blocks. Between them, "X.5" sessions did tight surgical work:

4.5 — fabrication purge (5 categories of invented specifics → placeholders)
4.5b — secondary fabrication purge (caught more after the first sweep)
5.5 — backfill founder bio + Gabi→Gabe rename across visitor-facing surfaces
5.5c — final Gabi→Gabe project-wide sweep + pronoun fixes (her→his)
8.5 — scope correction (deleted /schedule after learning Khanom Yoga doesn't run public classes; fixed a fish-spa card image mismatch)

Single commit per X.5. Constrained scope. Each one explicitly says "stay strictly inside this scope" and lists what NOT to do. They prevented the build from accumulating drift.

The voice pass (session 7)

The most judgment-heavy session. Voice editing isn't mechanical — there's no "right answer" the way schema validation has one. Risks:

Over-editing strips the brand voice instead of applying it
Voice creep — Claude Code's "direct, warm, precise" drifts from mine
Re-introduced fabrications under "rewriting for voice"
Hard-to-audit diff if 30 paragraphs change in one commit

Mitigations: a per-page audit format in BUILD-LOG.md with Before:, After:, and Why: (which BRAND.md rule drove the change) for every substantive edit. The diff became reviewable line-by-line. Owner could roll back anything that drifted.

The single best line that came out of it: rewriting the homepage hero from "A quieter coast. A practice you'll keep" to "A curated week. Not a hotel that offers yoga." — the §8 differentiation in nine words.

Photo curation (session 8)

The photo library had ~360 MB across 12 organized folders. Two filename conventions:

Descriptive (gabe-seated-aava-deck-direct-gaze.jpg) — could map specifically
iCloud UUIDs (random hex) — couldn't tell what the photo was without opening it

Solution: a two-stage workflow.

Stage 1 (Claude Code): copy a representative file from each folder into src/assets/images/photos/ with descriptive slot names, wire up all references, write PHOTO-MAPPING.md listing every slot's source file.
Stage 2 (owner, post-session): open each slot in Finder, swap any photos that aren't the best by replacing the file at the destination path.

Stage 1 made the site visually real today. Stage 2 doesn't block launch.

What's actually portable from this:

If you're doing similar work, the patterns that actually held up:

Architect / worker split with no shared context — forces explicit documentation; no implicit memory transfer.
Numbered prompts with three questions before coding — gives the worker a discipline checkpoint and the owner a chance to amend defaults.
Strict "don't invent — placeholder it" rule — repeated in every prompt, not just once.
BUILD-LOG.md with structured per-session entries — including before/after for voice/copy work — turns auditing from "trust me" into "verify this line."
X.5 cleanup sessions with strict scope — keeps the main sessions building forward while drift gets caught between them.
Cross-project markdown bridges (RELATED_PROJECTS.md, BRAND.md) for ecosystem coherence without sandbox coupling.

What's left for me: real Stripe Checkout links, owner content fills (the placeholders are my punch list), launch checklist execution, DNS swap. The build itself is at v1.0.

Worth the two days. The Kajabi template never loaded under 4 seconds; the new homepage is under one second on mobile and renders the brand voice in actual specifics rather than wellness fluff.

— Gabe

5 comments