fuzzyplace/living-stage

Living stage: guided setup

You are helping someone make their own version of this site: an ink character with a life of his own, arms that print the page as you scroll, their story in their words. The engine already works. Your job is to copy it, interview them, and fill in five places. Do not write engine code.

The five places that are theirs

What	File
Words: name, tagline, chapters, call to action, eggs	src/content/site.ts
Links in the link tree	src/content/links.ts
The character's look	src/content/character.tsx (presets in src/art/looks.tsx)
Palette, type, motion	design/tokens.json, mirrored in src/styles/tokens.css
Share image and icon	npm run og (generated from the above)

You also write the interview's decisions to docs/STORY.md, and you may read src/art/looks.tsx to copy a preset look into src/content/character.tsx.

Everything else (src/art/, src/audio/, src/components/, src/sections/, src/App.tsx) is the engine. Don't read it to do this job; it's large and you won't need it. Read docs/CHARACTER.md for the look and headline rules and docs/DESIGN_SYSTEM.md before touching tokens. Only open engine files if a check fails and the error points there.

Step 0: get the code (fast, no generation)

If the current folder is already a copy of the template (it has src/content/site.ts and .claude/skills/living-stage/), skip to step 1.

Otherwise ask where the new site should live (a folder name), then copy the template without its history and install it:

npx degit fuzzyplace/lil_guy_portfolio my-site
cd my-site
git init
npm install

Then start the dev server (npm run dev, or the preview tool if you have one) and show them the example site so they know what they're making. If you can't run or look at a dev server, use screenshots instead: npm run build && npm run verify writes screenshots/verify-desktop-hero.png (the hero, mid-stunt) and friends, and npm run looks writes close-ups of each look. (First time: npx playwright install chromium.) Tell them in two lines what will happen next: a short interview, one question at a time, then you build it, check it and (with their go) deploy it.

Step 1: the interview

How to decide (this matters most)

Decide top-down, one layer at a time, and never ask about a lower layer until the one above is locked. Visuals finished before the story and voice are settled lead to copy that doesn't make sense.

1. Intent: who the site is for, what they should feel, and what they should do at the end.
2. Story: the arc, scrolling top to bottom.
3. Copy style: voice, sentence shape, framing devices.
4. Structure: the blocks (chapters, a pop-out, contact) and what each one is for.
5. Lines: the actual words, tagline first.
6. Character: what he looks like.
7. Palette, type and motion.
8. Links: the link tree and the call to action.

Write each locked layer into docs/STORY.md under "LOCKED" (replace the example persona's entries as you go). Everything below must trace back to it. If a later idea contradicts a locked layer, say so and ask before changing anything.

How to ask

• One question at a time, in plain chat text. No multi-question forms or dialogs.
• Before each question, say in one line what it decides and what it changes on the page.
• Show, don't describe. For style and look questions give 3 or 4 options, each written out on their real content: the same three moments every time (the opening, one chapter, the ending). For the character, show the presets (?look=beanie|bun|hood|bot on the dev server, or npm run looks for close-ups). For palettes, show swatches with the text colour on the background.
• Recommend one option and say why in a sentence. They pick, mix or push back.
• After each answer, restate what's now locked in one line, write it to docs/STORY.md, then ask the next question.
• "Your call" means you decide, log it under "Decisions" in docs/STORY.md, and move on.
• Keep a running sense of cost: don't re-read files you've already read, don't regenerate the whole site for each answer, edit only the lines that changed.

What to ask, layer by layer

1. Intent. Who is this for (hiring managers, clients, collaborators, friends)? What should they feel? What's the one thing they should do at the end (email, book a call, follow, nothing)?
2. Story. Ask for the raw material first (what they did, do now, want next, anything they make on the side), then propose 2 or 3 arcs in one line each. The default arc is past, present, a pop-out with the through-line, future, contact; any order of chapters and pop-outs works.
3. Copy style. Offer 3 or 4 voices rendered on their own material, for example: quiet first person; lab notebook; field notes; terminal log; or a mix. Recommend one.
4. Structure. The list of blocks, each with its job in one line, plus which ones appear in the header nav. One block must be the contact block.
5. Lines. Draft every line in the locked voice, then show them together in context (the dev server, after writing site.ts). Get the tagline right first: read "Headlines" in docs/CHARACTER.md (2 to 4 short lines, a real word on the first line, tall letters beside short ones, a comma at a row end; at most 24 characters a line). Also: the eyebrow, the lede, the footer egg, the console egg, the two trust lines, the 404 line. Draft copy is fine; nothing ships until they approve it.
6. Character. Show the four presets. If none fits, ask for a one-sentence description (hair or hat, clothes, the one thing that catches the light) and draw a custom look by copying the closest preset into src/content/character.tsx and changing one shape at a time. Follow the box, joints and fill rules in docs/CHARACTER.md. Never trace a photo or a real person's likeness unless it is their own and they ask for it. The presets share parts.NECK and parts.SKULL (exported from src/art/looks.tsx). Show the result with npm run looks (screenshots/look-current.png).
7. Palette, type and motion. Offer 3 palettes as swatches (the default ink grays, and two that fit their story), the accent colour, and whether to keep the default fonts. Edit design/tokens.json first, mirror every colour you changed into src/styles/tokens.css (only the gray ramp has --md-ref-gray-* variables there; every other colour sits directly on its --md-sys-color-<role>), then npm run tokens:contrast: it checks text contrast (4.5:1) and that the two files agree. The fog (fog-light, fog-mid, fog-deep, fog-edge) carries the palette's mood: tint all four. Keep the accent a whisper (docs/DESIGN_SYSTEM.md). Motion: default durations or calmer (longer) ones.
8. Links. Ask for each link and where it goes (Connect, Work, Play, or renamed groups). Real URLs only: anything they don't have yet is href: null, status: 'soon' (shown in dev, hidden in production). Then the call to action: a booking link, an email, or a profile link.

Step 2: build and check

1. Write the content files from what's locked. Set site.url to where the site will live (https://host, no trailing slash). No domain yet: use the host's address (for example https://their-site.vercel.app) and update it later.
2. Run npm run check (types, tests including the copy rules, contrast and token drift, build). Fix what fails. The build warns while site.url still points at the template's demo (lil-guy-portfolio.vercel.app) or the call to action at example.com. The copy rules: no em or en dashes, no exclamation marks, no stock filler words.
3. Run npm run og for the share card and icon.
4. Run npm run build && npm run verify (first time: npx playwright install chromium). It checks at 1440 and 375, with and without reduced motion, that the character appears on load, does the entrance and the title stunt, stays on screen while scrolling, and that nothing errors. If no stunt plays, the tagline gives him nothing to stand on: revisit it with them.
5. Show them the screenshots (screenshots/verify-desktop-hero.png and verify-mobile-hero.png for the hero mid-stunt, verify-desktop.png and verify-mobile.png for the end of the page) and the dev server, and ask what to change. Loop until they're happy. node scripts/shots-sections.mjs gives one shot per chapter.
6. Privacy pass. Read every string in src/content/ once more. Flag anything they may not want public: a home address, a personal phone or email they didn't choose to share, family or health details, employers or clients they haven't cleared. Remove the example persona's leftovers: "Pim Lanternby", "PIM", "The Quiet Hour", lamp and radio lines, and any example.com, example.org or example.net link they didn't give you themselves, and the demo address lil-guy-portfolio.vercel.app.

Step 3: deploy

Deploying publishes their site, so ask before you do it. Follow docs/DEPLOY.md (Vercel by default; Netlify and GitHub Pages also work). After it's live, open the URL, check the share card with the deployed og.png, and give them the link.

Finish with a short summary: what's live, what's still soon, and anything they said they'd send later.