Arcade Skill / Play / Support

Tiny Browser Games While Your AI Agent Runs Tests

Search intent: Developers waiting on Codex, Claude Code, npm install, CI, or long local tests.

Real datapoint: Arcade Skill launches from a verified HTML bundle of about 20 KB and keeps ads disabled in localhost sessions.

Keyword focus: games while AI agent runs tests

This page is written for developer search intent.

The test-run waiting room

The best moment for Arcade Skill is not a lunch break or the end of the day. It is the awkward interval after a developer has asked an AI agent to run the boring part of the loop: install packages, regenerate a file, run unit tests, wait for a browser test suite, or inspect a long diff. The terminal is still the center of attention, but there is no useful human action for a minute or two. That is where a tiny browser arcade game belongs.

Why this beats opening a feed

Social feeds are optimized to steal the whole session. A heavy game asks for commitment. Arcade Skill sits between those extremes. Down 100 Floors starts quickly, ends quickly, and returns the player to the coding context with a score instead of a lost afternoon. The design target is one more run, not one more hour.

A developer-shaped loop

The installed skill keeps the mechanics small: a Python launcher, a manifest URL, sha256 verification, a local cache, and a browser window. The user can trigger it with plain language while Codex, Claude Code, or another agent keeps working. That makes the product feel like a sidecar for programming rather than a general arcade portal.

Measurement discipline

This scenario page is useful only if it leads to real behavior. The telemetry loop watches deaths, session length, replay intent, share clicks, and support clicks. If players bounce before learning the controls, the fix is game feel. If they play but never share, the fix is the score loop. Search traffic is treated as product signal, not just page views.

Search phrases this page owns

The language here is deliberately about CI pauses, Jest runs, Playwright retries, npm dependency installs, Python virtualenv rebuilds, package-lock churn, TypeScript checks, flaky assertions, local regression loops, green bars, terminal focus, pull-request review gaps, and the two-minute boredom that appears before a test suite finishes.

What a good session looks like

A good session starts after the command is already running. The player opens the game, drops through a few platforms, maybe reaches a new floor, copies a score, then returns to the terminal when the agent is ready. No login, no loot box, no live-service calendar, no notification permission, no giant asset download.

Why the bundle matters

The small verified bundle is part of the promise. A developer waiting on tests does not want another toolchain. The launcher checks the manifest, downloads a single HTML file, verifies the digest, and keeps a last-known-good cache. The technical shape supports the emotional goal: quick, trusted, disposable fun.

Fair scoring during test waits

In this context, score credibility is the product. If two developers compare runs while the same test suite is still running, the result has to mean something. Deeper floor wins, time breaks ties, and support payments must not add health, slow hazards, remove spikes, or change the daily seed.

How to use it with a test command

Start the boring command first, then open the game: run the test suite, wait for the package install, or let the agent finish its verification step. Use the hosted page for sharing and the installed skill for a local sidecar. When the command finishes, close the tab and go back to the terminal.

FAQ: test-run edition

Use this page when the query is about games during tests, CI waiting time, dependency install boredom, or small browser games for developers. Do not use it for broad gaming keywords; the intent is programming downtime.

Generated

2026-07-16. This draft is safe to review, edit, and publish through the normal repo flow.