game-playtest
Run browser-game playtests and frontend QA. Use when the user asks for smoke tests, screenshot-based verification, browser automation, HUD or overlay review, or structured issue-finding in a browser game.
Best use case
game-playtest is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Run browser-game playtests and frontend QA. Use when the user asks for smoke tests, screenshot-based verification, browser automation, HUD or overlay review, or structured issue-finding in a browser game.
Teams using game-playtest should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/game-playtest/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How game-playtest Compares
| Feature / Agent | game-playtest | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Run browser-game playtests and frontend QA. Use when the user asks for smoke tests, screenshot-based verification, browser automation, HUD or overlay review, or structured issue-finding in a browser game.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
Related Guides
SKILL.md Source
# Game Playtest ## Overview Use this skill to test browser games the way players experience them: through boot, input, scene transitions, HUD readability, and visual state changes. Prefer browser automation and screenshot review when the project supports it. ## Preferred Workflow 1. Boot the game and confirm the first actionable screen. 2. Exercise the main verbs. 3. Capture screenshots from representative states. 4. Check the UI layer independently from the render layer. 5. Report findings in severity order with reproduction steps. ## Tooling Guidance - Prefer Playwright or equivalent browser automation already available in the repo. - When the game is canvas or WebGL heavy, screenshots are mandatory because DOM assertions alone miss visual regressions. - Use screenshots to judge playfield obstruction and HUD weight, not just correctness of text or layout. - When deterministic automation is not practical, do a structured manual pass and capture evidence. - For 3D rendering bugs or unexplained frame cost, use SpectorJS and browser performance tooling rather than guessing from code alone. ## Common Checks ### 2D checks - sprite alignment and baseline consistency - hit or hurt animation readability - HUD overlap with the playfield - command menu state changes - tile or platform readability - input-state feedback and turn-state clarity ### 3D checks - first-load playability versus dashboard-like chrome - persistent overlay weight versus playfield visibility - camera control and camera reset behavior - pointer-lock or drag-look transitions when menus and overlays open - depth readability and silhouette clarity - secondary panels collapsed or dismissible during normal play - resize behavior - WebGL context loss or renderer fallback behavior - material or lighting regressions - GLB or texture streaming stalls - collision proxy or physics mismatch - performance cliffs tied to post-processing or asset load ## Responsive and Browser Checks - desktop and mobile viewport sanity - safe-area and notch issues where relevant - reduced-motion behavior for UI transitions - keyboard, pointer, and pause-state handling - React state and scene state synchronization when the project uses React Three Fiber ## Reporting Standard Lead with findings. Keep each finding concrete: - what the user sees - how to reproduce it - why it matters - what likely subsystem owns it ## References - Shared architecture: `../web-game-foundations/SKILL.md` - Frontend review cues: `../game-ui-frontend/SKILL.md` - 3D debugging notes: `../../references/webgl-debugging-and-performance.md` - Full checklist: `../../references/playtest-checklist.md`
Related Skills
web-game-foundations
Set browser-game architecture before implementation. Use when the user needs engine choice, simulation and render boundaries, input model, asset organization, or save/debug/performance strategy.
three-webgl-game
Implement browser-game runtimes with plain Three.js. Use when the user wants imperative scene control in TypeScript or Vite with GLB assets, loaders, physics, and low-level WebGL debugging.
react-three-fiber-game
Build React-hosted 3D browser games with React Three Fiber. Use when the user wants pmndrs-based scene composition, shared React state, and 3D HUD integration inside a React app.
phaser-2d-game
Implement 2D browser games with Phaser. Use when the user wants a Phaser, TypeScript, and Vite stack for scenes, gameplay systems, cameras, sprite animation, and DOM-overlay HUD patterns.
game-ui-frontend
Design UI surfaces for browser games. Use when the user asks for HUDs, menus, overlays, responsive layouts, or visual direction that must protect the playfield.
game-studio
Route early browser-game work. Use when the user needs stack selection and workflow planning across design, implementation, assets, and playtesting before moving to a specialist skill.
workflow
Vercel Workflow DevKit (WDK) expert guidance. Use when building durable workflows, long-running tasks, API routes or agents that need pause/resume, retries, step-based execution, or crash-safe orchestration with Vercel Workflow.
verification
Full-story verification — infers what the user is building, then verifies the complete flow end-to-end: browser → API → data → response. Triggers on dev server start and 'why isn't this working' signals.
vercel-storage
Vercel storage expert guidance — Blob, Edge Config, and Marketplace storage (Neon Postgres, Upstash Redis). Use when choosing, configuring, or using data storage with Vercel applications.
vercel-services
Vercel Services — deploy multiple services within a single Vercel project. Use for monorepo layouts or when combining a backend (Python, Go) with a frontend (Next.js, Vite) in one deployment.
vercel-sandbox
Vercel Sandbox guidance — ephemeral Firecracker microVMs for running untrusted code safely. Supports AI agents, code generation, and experimentation. Use when executing user-generated or AI-generated code in isolation.
vercel-queues
Vercel Queues guidance (public beta) — durable event streaming with topics, consumer groups, retries, and delayed delivery. $0.60/1M ops. Powers Workflow DevKit. Use when building async processing, fan-out patterns, or event-driven architectures.