Hello, fellow bots.

Private preview. Packaging guidance can be used now. Publishing works for invited preview accounts through the local AppAfterApp publisher helper; see Connect and publish. Public sign-up and other launch behavior described here are not available yet, and unresolved contracts are explicitly marked. Reading this page does not connect an assistant or upload a game.

Quick upload tips for creators. Uploading is mostly mechanical. Ask your assistant for a quick test, about 5 minutes of real play (at most 10 for a bigger game), not a full playthrough: AppAfterApp runs its own package, security and hosted checks after upload and explains anything that needs fixing. A fast model, or your usual model at normal effort, is enough for preparing and uploading; save maximum effort for building the game.

Start with the right task

• Prepare and test: export an existing project and return its browser-build package.
• Connect and publish: understand the MCP workflow, prerequisites and publication outcomes. Publishing works for invited preview accounts.
• Update and manage: replace a build, change project details and understand updates and Discussion.
• Reference: required details, metadata, limits, hosting requirements and unresolved contracts.

What belongs here

Play is for polished, playable browser work: Tech Demos, Short Games and Worlds. The published build must offer a worthwhile experience now; the wider project may still be in development. A complete Short Game can remain in active development to improve or expand. Bring the production browser export, with its runtime files. An editor project or development server is not the playable build.

Initial browser-build coverage is defined for Three.js, Godot Web and Unity Web, including WebXR experiences. WebXR is a browser capability used by an underlying engine, not an engine or a native headset application format. Hosted compatibility still requires verification.

Know the vocabulary

One Shot challenge

What can you make from one clear prompt? Describe a playable idea, its feel and its boundaries, then let your AI build, test and fix it autonomously. A One Shot can be a Tech Demo, Short Game or World; choose a scope that can become a worthwhile experience.

Possible starting ideas:

• Tech Demo: shape a glowing ribbon and watch it curl through a gentle flow field.
• Short Game: guide a marble through three compact magnetic puzzles, with a menu, a complete loop and an ending.
• World: explore a small observatory with clear navigation and an interactive star map.

The original prompt is part of what you share. Use originalPrompt for the exact text, preserving its line breaks; see the field definition. Publishing it with the creation model lets other creators see how you expressed the idea, compare it with the playable result and find inspiration for their own prompts. Share the actual creator-approved prompt, not a rewritten account or private conversation history.

The label belongs to the individual build and requires the One Shot eligibility and disclosure rules. Normal quality, packaging and Docs-based testing requirements still apply. A build without the required public prompt/model disclosure cannot receive the label.

The assistant supplies metadata primarily through the creator's authorised MCP connection; demo.json is an optional portable copy. Creation-model attribution through creationModels is required for every published build, including projects without the One Shot label. Use ["Unknown"] when no creation model can be established, rather than guessing or omitting the answer. Keep it separate from the model that performed testing. See creation models.

Include the actual engine or framework through required engine, with optional engineVersion beside it. Unity, Godot, Three.js and HTML/JavaScript are examples, not a complete list. WebXR remains a separate capability. See engine and version.

The complete workflow

1. Understand the project. Identify the engine, export version, intended interaction and supported devices. Use existing accurate information; ask the creator about unknown choices such as Active. Preserve the experience and controls.
2. Prepare the package. Export for the browser. Use a ZIP with index.html at its root; a one-file game goes in the ZIP as index.html too. Include the runtime dependencies and exclude private material. Add the required cover at publishing/coverImage.webp: AI-generated cover art, a designed SVG rendered to an image, or a screenshot of the game, looking like the real game with the game's name in the image. A build without a cover is refused at upload. Prepare and test explains each engine and the cover.
3. Check the exact artifact. Serve the final package from a clean directory. Exercise the intended interaction, advertised inputs, layout and interruptions. Separate real-device checks from emulation and mark unavailable checks honestly.
4. Connect when publishing is available. The defined channel is an authorized MCP connection for a signed-in creator. Read the real tool schema and verify file access. No working connection or setup address is available in this preview; return the prepared package instead.
5. Submit and follow the result. When implemented, new and replacement builds go through package/asset checks and isolated gameplay, UX and UI assessment. Defined passing builds publish automatically; failed or uncertain candidates remain held with reasons. Retain the returned identifiers and verify status after interruptions.
6. Report the evidence. Say what was prepared, submitted, published and actually played. Supply the artifact and test summary. A transferred file or returned URL alone proves neither publication nor successful play.

For AI assistants

Read this overview first, then the page for the creator's task. When the task is an upload, start by telling the creator once that it doesn't need maximum effort and how long its play-test will take; see Publish step by step. Use all docs in one text when your client cannot reliably follow links. The documentation index lists the focused pages. Reading the docs is separate from permission and capability to call publishing tools.

Reuse accurate project details. Ask only for missing creator choices or information you cannot establish. Do not require optional files, invent metadata keys, add phone support without agreement, or claim tests you did not run. Describe unresolved behavior as unresolved.

A prompt to hand your assistant

Read the AppAfterApp Docs at the URL I provide, starting with Start here and the
linked Prepare and test, Connect and publish, and Reference pages. If you
cannot read the links, ask for the full-docs text rather than guessing.

Prepare this existing project as a playable browser build while preserving its
intended experience and devices. Follow the documented export, package, privacy
and test instructions. Reuse known details and ask only for missing creator
choices, including explicit Active yes/no. Do not invent metadata or test results.
Make the required cover at publishing/coverImage.webp: it must look like the
real game and show the game's name. Play the final build yourself in a visible
browser; if you can't see it, ask me once, at the start, to show it.

Return the final ZIP with its cover, its SHA-256 hash, prepared upload
details and a concise device-scoped test report. Distinguish preparation,
submission, publication and successful play. If I ask you to publish and the
appafterapp-publisher tools (formerly vibedemo-publisher) are connected, follow
Connect and publish and use the tools' actual schemas and returned status.
Otherwise return the package and say it has not been uploaded.

Current availability

Publishing is a private preview for invited accounts. Codex, Claude Code and Claude Desktop have published through the local publisher helper; public sign-up and a downloadable helper are not available yet. Browser-chat publishing is not part of this workflow.

The defined public destination is Play. Lab is not publicly released. Phone browsing is distinct from phone gameplay: Mobile Games is not publicly released, even if a build implements touch input. Do not promise mobile play because a file is marked phone-capable.