Release preparation must be tied to the actual Experience, Place, and version state. Before starting, readplugin routing、control model, asset licenses, QA evidence, and online data change records.
Responsibilities and Inputs
- Confirm Studio instances via list_roblox_studios; get_studio_state only reports the running mode and available DataModel, not Place identity. Confirm Experience/Place via verified read-only queries or user-provided information.
- Check the user-approved target players/platforms, version changes, Remote security, asset permissions, privacy statements, and known risks; evaluate legacy data migration or old client compatibility only when the requirements explicitly call for it, and by default do not add a legacy compatibility layer.
- When there are substantive choices regarding release targets, public scope, monetization, data handling, online service writes, or rollback impact, first organize the facts, options, impacts, and recommendations.
- If there are still human trade-offs that cannot be resolved by evidence regarding the release object/scope, asset licenses, public status, monetization, data risks, or rollback impact, hand them toRoblox Game Interrogationto obtain and record an explicit decision; being ready does not equal being authorized to upload or release. After approval, return to the original release work item.
- Studio plugins currently have no publish/build tool routing; this skill can prepare review materials and manual steps, but must not fabricate that a release has been completed.
Release Preparation Steps
When there is aproject checklist, the release work item transitively depends on the final integration item and pins its candidate. Before release, use status-project to verify that production and the integration item are complete; it is normal for the release item to be incomplete because there is no release result yet, and PASS must not be pre-filled. After obtaining an authorized real release result, use check-project to aggregate the final delivery. For multiple Places, check each target, relationship contract, and evidence only according to the project's explicit configuration, and do not automatically publish other Places.
- Build a candidate checklist: Experience/Place identity, source changes, version notes, feature scope, dependencies, asset IDs, and approved platform scope.
- Verify completed QA results, console errors, uncovered multiplayer/device scenarios, and remaining blockers; developer self-checks cannot replace independent QA.
- Review Remote validation and server authority, Player lifecycle cleanup, Streaming assumptions, PurchaseId idempotency, and online rollback impact; review legacy data migration or old client compatibility only when the project explicitly requires it.
- Confirm authorization item by item for models, audio, fonts, textures, animations, and external assets; retain the source and scope of use.
- Draft the experience description, update notes, privacy/data handling changes, features visible to target players, and known issues, without exaggerating unverified behavior.
- Prepare a phased enablement and rollback plan: trigger thresholds, monitoring metrics, responsible parties, recovery configuration/version path, and remediation plans when data cannot be rolled back.
- Make the actual release submission, rewriting of online configuration, upload, or public release a separate protected operation; enter the corresponding manual release process only after explicit authorization.
Delivery and Release
- Deliver the candidate checklist, QA/asset/license/data evidence index, known issues, canary plan, rollback plan, and manual steps.
- Clarify which checks passed, failed, were blocked, or did not run; if there are no release tool results, the status remains "not released".
- Verify the publishing entity, target Place, and version record through verifiable information; get_studio_state is not used as evidence of Place identity, and when information is missing or inconsistent, mark it as unverified and return it to the planner for confirmation.
- After release, record the actual external results, visible version, and rollback status; readiness must not be written as already live.
- Basis for QA release QA and performance actual evidence; the candidate scope comes from production planning。
Do not on your own enable live DataStore, public experiences, upload assets, or perform releases. Any missing approval, permission, QA evidence, or candidate identity should be treated as a blocker.
Rollback and incident preparation
- Rollback steps must match the actual place/version management method, and it must be confirmed in advance whether they will affect saved player data.
- A code version rollback cannot automatically undo purchases already granted, saves already written, or player notifications already sent.
- Only when the project explicitly requires compatibility/migration of existing data should old-record handling be designed for added, deleted, or renamed fields; by default, implement according to the current target data format and do not add a legacy compatibility layer.
- The release checklist should record key asset IDs and license status to avoid blanks at release time due to private assets or unavailable review status.
- For key experience flows, list the permission, privacy, transaction, and UGC entry points that must be rechecked before public access.
- Rollback candidates should retain verifiable version identity, change records, the person responsible for recovery, and the observation window.
- External platform approval, discoverability, public status, and actual live player behavior cannot be inferred from local Studio status.
- If you do not have permission to read the Creator Dashboard or live version status, mark the corresponding items as unverified and have the experience owner check them.