wai-play

name	wai-play
description	Route web-game auto-playtesting with WAI Play (waiterve/wai-play): decide whether the next move is a testability check, authoring or repairing the `GameFlowAgentAPI` bridge, running a real browser playtest, reading the five-dimension quality report, or unblocking a key node the agent cannot reach. Use when the user wants an AI agent to actually play their HTML5 / canvas / vibe-coded web game and return reproducible evidence, scores, and fix suggestions across the five supported types (survivor-like, arcade shooter, platformer, puzzle/card, visual novel). Triggers on: wai-play, WAI Play, auto-playtest, AI plays my game, web game testing agent, GameFlowAgentAPI, GameFlowIntegration, jumpToScenario, game quality score, playtest evidence. Route Unity/Unreal frame-time work to `game-performance-profiler`, engine build failures to `game-build-log-triage`, human playtest notes to `game-demo-feedback-triage`, and generic browser automation to `browser-harness`.
allowed-tools	Bash Read Write Edit Glob Grep
compatibility	Python 3.12 recommended. Runs locally as a Streamlit app with Playwright Chromium (`streamlit`, `playwright`, `openai`, `python-dotenv`). DeepSeek (planner) and Kimi (reporter) API keys are optional but degrade source modeling, route planning, and natural-language suggestions when absent. The upstream UI and reports are Chinese-language. Docker image available.
metadata	{"tags":"wai-play, web-game-testing, auto-playtest, game-qa, playwright, streamlit, gameflow-agent-api, evidence, game-scoring, html5-game","platforms":"Claude, ChatGPT, Gemini, Codex","version":"1.0","source":"https://github.com/waiterve/wai-play"}

WAI Play — agent auto-playtesting for web games

WAI Play drives a real browser against a running web game, models the game's goal and key nodes, plays it, and returns a five-dimension quality score with reproducible problem cards (state deltas, screenshots, ≤20 s clips) and fix suggestions. Test credibility is reported separately from game quality, so a weak harness never inflates or deflates the game's score.

The work almost never starts at "run the test". It starts at can this game be tested at all, and that answer decides everything downstream.

When to use this skill

• A vibe-coded web game needs an automated play-through before a demo, jam deadline, or release, and the user wants evidence rather than vibes
• The game has no agent-readable state and needs a GameFlowAgentAPI bridge authored or repaired
• A test run finished and the user needs help reading the score, the problem cards, or the credibility diagnostics
• A required key node (first upgrade, boss phase, level goal, ending) cannot be reached and the user must choose between repairing preconditions, jumping, or taking the natural route
• The user is deciding between local, Docker, and keyless (degraded) operation

When not to use this skill

• Unity / Unreal frame-time or profiler work → game-performance-profiler
• Engine build, cook, or package failures → game-build-log-triage
• Human playtest notes, Steam Playtest responses, streamer reactions → game-demo-feedback-triage
• General browser automation or a scripted E2E suite with no game model → browser-harness or playwriter
• Building the game itself rather than testing it → web-game-development

Instructions

Step 1: Capture the intake packet before touching the tool

Collect five facts. Missing any of them changes the recommendation:

1. Game type — one of survivor_like, arcade_shooter, platformer, puzzle_card, visual_novel. WAI Play supports these five and nothing else; a game outside them gets the closest profile plus a stated caveat.
2. Reachable URL — the running game, not a repo. Localhost is fine.
3. Integration state — does the page expose window.GameFlowAgentAPI? URL-only black-box testing works, but flow modeling and key-node routing are markedly weaker without it.