---
name: ryan-arcade-builder
description: "Build and test Ryan's browser arcade workflows. Use when adding publicly playable arcade games, optional verified-account sharing, mobile touch controls, Three.js scenes, accessible HUDs, or Firebase-hosted game pages."
---

# Ryan arcade builder

Original authored for Ryan's arcade, with AI assistance, from the project's own browser-game workflows. Not a downloaded skill or a claim of personal human authorship. No third-party skill text is imported. This publication does not grant a blanket license to the site's code, art, brands, or other content.

## Scope

Use in Ryan's portfolio `web` project for `/arcade.html`, `/pimp-my-ride.html`, and `/drive-my-ride.html`. These public instructions are reusable; they contain no account IDs or credentials. Discovery, game play, and skill downloads are public; verified accounts are required only for community ride sharing and the showroom.

## Procedure

1. Read the specific game's HTML, controller, pure simulation module, and corresponding `tests` files before changing behavior. Keep the physics/model layer separate from account, DOM, persistence, and rendering code. Use the existing local `public/vendor/three/three.module.js` import when extending existing renderers; do not introduce a CDN dependency or copy vendor code into skills.
2. Keep game play independent of account state. Verified Google/GitHub sign-in is required only for community ride sharing and showroom reads; await `accountReady`, reject stale asynchronous verification after account changes, and keep the Firestore rules and controller checks. A sign-in failure must not block a default ride, local customization, or a race.
3. Keep all JavaScript and CSS external for Firebase Hosting's strict CSP. Do not add inline event handlers, inline executable scripts, `eval`, or a new remote script origin to make a feature work.
4. Design for a narrow mobile viewport first, then landscape and desktop. Make canvas sizing follow its container, keep HUD text readable, respect safe areas, and test that controls do not overflow or cover the course. Support keyboard and touch together. Release held input on blur, visibility changes, pointer cancellation, account changes, and leaving play.
5. Reuse shared ride data rather than creating a second schema. Read `public/ride-data.js` before extending garage or race features. Use `newRide`, `validateRide`, `serializeRide`, and `parseSavedRide`; never trust saved gallery data simply because it came from the database.
6. Preserve model provenance. The cars are detailed GLBs in `public/models/rides/`: two original Blender-authored models and one adapted CC BY 4.0 concept car, recorded in `provenance.json` and `credits.html`. Follow the `ride-customizer` skill for creating or replacing vehicle assets, `hometown-racer` for racing, and `eat-my-face` for the maze game. Any new model needs documented source, author, license, permitted redistribution, attribution, and texture rights. Do not invent permission, claim vehicle-brand endorsement, or publish third-party skill collections.
7. Prefer deterministic, pure simulation tests before browser checks. From `web`, run `node --test tests/arcade.test.js tests/arcade-screen.test.js tests/ride.test.js tests/ride-model.test.js tests/ride-ui.test.js tests/drive.test.js`. Run account tests when access changes: `node --test tests/account.test.js`. Consult existing emulator setup before running Firestore-rule tests; never use production data as test fixtures.
8. Verify signed-out, unsupported-provider, failed-verification, signed-in, sign-out-during-load, keyboard, touch, and narrow-screen states. Check browser errors, canvas resize, pause/resume, and input cleanup. When working on racing, test AI finish progression, not just a moving car.

## Acceptance

Report the behavior changed, targeted test commands/results, viewport checks, and any unverified account/emulator cases. Never imply an emulator test proved live authorization or deploy/bill without explicit authorization.