Update to PlayDrop

{
  "description": "Develop, test, publish, improve listings and distribute creator-owned browser games on PlayDrop when the user asks to use PlayDrop. Use its connector tools and current documentation for complete uploads, retained versions, SDK features and game views.",
  "included_files": [],
  "name": "playdrop-ai",
  "skill_md_contents": "---\nname: playdrop-ai\ndescription: Develop, test, publish, improve listings and distribute creator-owned browser games on PlayDrop when the user asks to use PlayDrop. Use its connector tools and current documentation for complete uploads, retained versions, SDK features and game views.\n---\n\n# PlayDrop\n\nHelp the creator make the best game they can, give it a strong listing and reach players on PlayDrop.\nThe creator owns and maintains their code with their coding agent. Uploaded games and PlayDrop Studio games\nare separate: do not read Studio source, request Studio tasks, update Studio games or use them as upload dependencies. Studio library cards expose only basic\nmetadata and a link to continue on PlayDrop. There is no bulk-delete tool; do not substitute uploads, publication or cancellation for deletion.\n\n## Establish the available capabilities\n\nUse `get_account` and `list_games` to check the connected creator and owned games. Read `get_documentation`\nfor current `catalogue`, `sdk` and `server-sdk` contracts before using advanced features. Never request or expose\npasswords, OAuth credentials or component grants in conversation.\n\nUse the tools actually available on this connection. Catalogue uploads, version inspection, publication and\nExtensions are normal connector capabilities. If a host does not expose a tool, use its available upload tools\nor the website and explain that limitation. Do not claim a deployment or review verdict without evidence.\n\n## Develop, test and upload a complete game\n\nFor a simple self-contained HTML game, use `upload_game` with the HTML and explicit private visibility.\nThis is the shortest upload path when no extra files or listing media are requested. Keep any supplied media,\nserver code and dependencies: use the complete catalogue workflow below when the upload includes those files.\nDo not simplify a complete game into HTML alone to bypass a transport failure.\n\n1. Build in the creator's project and keep original source there. Keep the same game identity and slug on updates.\n2. When developing locally, start the game server and open\n   `https://www.playdrop.ai/creators/<username>/apps/game/<slug>/dev?url=<encoded loopback URL>`\n   in a compatible browser on the same machine. URL-encode the full local URL. Use the built-in browser if it\n   supports local-network access, otherwise the creator's ordinary browser with its normal permission flow.\n   Verify input and rendering through the PlayDrop host and SDK; standalone localhost is insufficient.\n   Keep the server running, report which browser passed, and do not disable browser security, use a tunnel,\n   upload a substitute Dev version or send local Dev context to `show_game_panel`.\n   This local development step is unnecessary when uploading already-created attachments.\n3. Prepare a complete `catalogue.json`, listing and file manifest. Every push is a full snapshot: include every\n   desired field and every desired file. Omitted optional fields follow replacement semantics; omitted catalogue\n   items are not deleted. An explicit reused file from an owned retained version must appear in the new manifest.\n   Supply each app's visibility explicitly, or set the catalogue request's visibility. Prefer private testing.\n   Baked procedural 2D assets are supported. Executable procedural/CUSTOM 3D uploads are unsupported through\n   the connector. Reference an existing supported asset revision or upload a baked supported format instead;\n   do not execute creator modules in the API.\n4. Where available, use `prepare_catalogue_upload`, transport every declared file, then\n   `complete_catalogue_upload`. Support signed byte uploads, inline text and host-provided file attachments\n   according to the tool schema. For ChatGPT attachments, pass individual runtime/media file references through\n   top-level `attachments`. Map each manifest path with `attachmentIndex`, its zero-based position in that\n   array: for `attachments: [htmlFile, iconFile]`, use `{path: \"game/index.html\", attachmentIndex: 0}` and\n   `{path: \"media/icon.png\", attachmentIndex: 1}`. ChatGPT resolves those references into download objects\n   after the model call; do not bind manifest paths to internal file IDs or filenames.\n   PlayDrop fetches the bytes server-side. Inline text remains suitable for HTML; local coding agents can PUT\n   signed uploads directly. The tool does not unpack ZIPs: attach the contained files individually. Never invent\n   file IDs or download URLs, and do not drop listing media to hide a transport failure. If the installed tool\n   lacks this attachment contract and the host cannot reach signed storage, report the blocked transport.\n   Keep the request ID and returned per-item receipts; resume the same upload\n   after a partial or ambiguous result. Report committed items and unfinished items honestly. Cancel only an\n   upload the user intends to abandon.\n5. Prefer private testing before publication when requested. Review admission applies to each\n   exact MCP-uploaded version, including private drafts. An unfinished review is not an eligible verdict.\n\nMake gameplay responsive and use device safe areas. English and the creator's language should have complete\nlistings and localized artwork when requested. Listing icons, screenshots, landscape trailers and portrait\nteasers should reflect the actual game. The optional PlayDrop SDK supports saves, leaderboards, achievements,\nsocial features and multiplayer. Read current docs for hosted Colyseus game servers and asset/spec/pack support.\n\n## Inspect, publish and improve\n\nUse `list_game_versions` and `get_game_version` when available to inspect exact uploaded artifacts, visibility,\nretention, listing, review feedback and distribution. Keep original source in the creator's local project;\nnever promise a cloud source-code editor.\n\n`publish_game_version` publishes a selected retained version without new bytes or a new version number.\nRead the current public version first and supply `expectedCurrentVersion`. On a stale expectation, explain the\nconflict and refresh the selection; do not silently replace a newer publication. Publication preserves the\nselected version's existing review. Private uploads must not change the live listing or tags.\n\nReturn canonical `/@creator/game-slug` links with the exact public version for Live playback. Owners can have\nnewer private drafts, so do not present a draft as Live. Distribution follows the returned review/discovery\nstatus and varies by surface; do not promise search placement or recommendations before eligibility.\nUse review feedback to improve gameplay and listing, then upload another complete snapshot.\n\n## Extensions behavior\n\nThe Sidebar library shows owned game cards with Live, Draft or Studio status. Clicking an uploaded game\nopens its latest retained version for playtesting. Studio cards show an Open in PlayDrop handoff; the connector\ncannot read or change their source. There are no per-card Play/Update buttons or separate creation prompt.\nUse the host conversation composer for creating games and requesting changes.\n\nThe Conversation panel contains only the game player and Live / Draft controls. Live resolves the exact\ncurrent public version; Draft selects an exact private version or the latest draft. Missing versions show clear\nempty states. `show_game_panel` accepts empty input for game selection, or the chosen game/version/environment.\nUse it to test uploaded versions; local Dev belongs in the browser workflow above. Editor and Assets views are\noutside this first release. Game updates remain complete uploads from the creator's coding agent; do not invoke\nStudio tasks.\n\nUse `send_feedback` when the user asks to report a PlayDrop issue or suggestion. Include useful reproduction\nsteps and observed errors without credentials or private source unrelated to the report.\n"
}