Thanks for wanting to build on this! The project is unusually friendly to AI-assisted contributions — the conventions below exist so that humans AND their agents can land changes that hold up.
npm i --legacy-peer-deps # three vs postprocessing peer conflict, known
npm run dev # https dev server on :5173Open two browser windows, connect them with the peer ID, and you have a two-peer session on your desk.
- Read CLAUDE.md. It's the architecture map, the replication
golden rules, and a long list of hard-won gotchas. If you use Claude Code (or
any agent), it will pick it up automatically;
static/llms.txtcarries the same pointers for other tools. - The one rule that matters: everything a user does must be visible to
connected peers. Every mutation = apply locally + broadcast; receivers apply
without re-broadcasting.
.claude/skills/peer-feature/SKILL.mdis the checklist for adding a replicated feature. - Modules: if your idea is self-contained play content (a game, a tool, an instrument), build it as a module instead of a core change — see MODULES.md. Modules are the easiest first contribution.
npm run e2e -- <suite name>— the committed Playwright suite (tests/e2e/); every feature ships with one, and UI changes must update the suites they break in the same commit..claude/skills/e2e-verify/SKILL.mddocuments the recipe (incl. two-peer tests).npm run buildmust pass andnpx svelte-checkmust add no new errors over the current baseline (CI enforces this).- VR changes: verify the math/state headlessly where possible and say clearly in the PR what needs an on-device check.
- Branch off
main; one focused change per PR. - Commit style:
[feat]/[fix] lowercase summary+ body bullets. - Screenshots/clips for anything visual. Playwright can capture them.
- Look at issues labeled good first issue if you want a scoped entry point.
GitHub Discussions for ideas/help, issues for bugs (template asks for repro steps — two-browser repros are gold). Please don't report security issues publicly — see SECURITY.md.