What a prototype playground needs before the prototypesWhat a prototype playground needs before the prototypes

The first thing that went wrong in my team's prototype playground was that nobody could open the prototypes. The playground holds the design system components, an instructions file for agents, automated checks and sharing and preview links, and the preview links were the piece we treated as an afterthought. A prototype that a reviewer cannot open in a minute never gets reviewed, so the sharing path belongs in the first version of a playground, ahead of the checks and ahead of the rules.

What the playground has to be made of

Prototypes assembled from the real components graduate with little rework, because the thing being reviewed is already a candidate for production. The instructions file keeps every agent session building from those components, in the form I describe in writing the CLAUDE.md for a design system. The automated checks tell a reviewer which prototypes are broken before anyone spends time on them. A product designer at Notion AI has described a shared Next.js playground built on Claude Code where designers create, share and iterate on running prototypes (Lenny's Newsletter), and the case for it applies to anything with a model inside: a static frame shows one response, and a running prototype can sample the range.

What parallel sessions add

Once several people or agents prototype at once, the second problem arrives, and this site's repository has been through it with parallel Claude Code sessions. The repo keeps each session in a git worktree under .claude/worktrees, on its own branch (two current ones are first-and-texas and planner-job-progress), so two agents never edit the same checkout. The cost shows up later: the code review plan from 2026-10-21 includes deleting six merged agent worktrees that took up 2.5 GB, and the same item records that npm run lint was exiting 1 on worktree and sync-directory noise, so the checks everyone relied on were failing before any code was wrong.

The staging area is still shared. The plan's ground rules say to stage and commit in one command, because other sessions and a publish script commit whatever is staged, and issue #76 records that the script's commit has no pathspec and sweeps the index. A half-finished prototype that someone stages and walks away from can end up committed by someone else's automation.

One branch per phase, one kickoff prompt

The plan names a branch per phase of work (review/phase-1-security is the example) and merges to main when the phase's checklist passes. Phase 0 comes first and makes lint, the type check and the tests trustworthy, because every later phase relies on them. Every session starts from the same kickoff prompt: read the plan and CLAUDE.md, work the issues in the listed order, make the fix on a branch, add the tests the issue names, run lint, the type check and the full test run, commit with the issue number, and stop and ask before anything on a short list. The prompt turns a blank session into a predictable one.

What to set up on day one

Set up the preview links first and test them with someone who has never seen the repo. Give each session its own worktree and branch, and plan the cleanup that goes with them. Write the kickoff prompt before the first parallel session, and make the checks pass on a clean checkout before anyone relies on them. Label what has graduated to production and keep a short list of what a prototype may never touch, since prototypes in code can drift into production without anyone deciding they should. Prototype fidelity by stage covers how much polish each stage deserves.