Guide changes to existing Roblox Studio projects by inspecting their structure, reusing components, and choosing where scripts run. Cover server, client, and device testing, inspect logs, and clean up temporary objects before reporting results.
Modify living Roblox Studio projects safely: inspect Explorer and execution locations, preserve existing structure, reuse modules/remotes, create meaningful Instances, apply Attributes and CollectionService tags, test server/client and multiple devices, inspect Output, and remove experiments/debug objects. Use when an agent edits a place or rbxl/rbxlx/Rojo project, operates in Studio, adds Scripts/LocalScripts/ModuleScripts, or must verify a Roblox change in context.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
Work as a collaborator inside an existing place, not as if it were a blank text repository. Targets current Roblox Studio and rolling platform APIs.
When not to use: this skill owns project operation, not the domain implementation. Compose it
with roblox-ui, roblox-networking, roblox-characters, roblox-physics, roblox-luau, or
roblox-datastores as appropriate.
StarterPlayerScripts, per-character client logic in
StarterCharacterScripts, UI templates in StarterGui, shared assets/modules/remotes in
ReplicatedStorage, and secrets/server assets in server-only containers.| Location | Typical role | Key constraint |
|---|---|---|
ServerScriptService | authoritative server Scripts/modules | not replicated to clients |
ServerStorage | server-only assets/data | clients cannot access it |
ReplicatedStorage | shared modules/assets/remotes | visible to clients; do not store secrets |
StarterPlayerScripts | client systems across respawns | clone into PlayerScripts |
StarterCharacterScripts | per-character client behavior | recreated each character |
StarterGui | authored UI templates | clones into PlayerGui; lifecycle depends on GUI policy |
Workspace | replicated world and live characters | streaming/ownership may affect client view |
Verify actual Script RunContext and project conventions; class/location shorthand does not excuse
inspection of an existing custom setup.
Before creating a RemoteEvent, search by purpose and inspect both endpoints. Before adding a “manager” or service module, identify the current feature owner. Before introducing folders/tags, inspect naming and retrieval patterns. Duplicate systems are especially dangerous when both run: they double-bind input, save twice, create two UI clones, or apply gameplay twice.
Use Attributes for small typed designer-editable metadata that belongs on an Instance. Use
CollectionService tags for discovering sets of Instances across hierarchy. Use folders for
ownership/navigation, not as a substitute for semantic tags. Preserve established schemas and
validate missing/malformed Attributes at system boundaries.
local CollectionService = game:GetService("CollectionService")
local function setupDoor(instance: Instance)
if not instance:IsA("Model") then return end
local accessLevel = instance:GetAttribute("AccessLevel")
if type(accessLevel) ~= "number" then
warn(`Door {instance:GetFullName()} needs numeric AccessLevel`)
return
end
attachDoorBehavior(instance, accessLevel)
end
for _, door in CollectionService:GetTagged("Door") do setupDoor(door) end
CollectionService:GetInstanceAddedSignal("Door"):Connect(setupDoor)
The owning system must also clean behavior when a tagged Instance is removed/destroyed.
Roblox Studio has a built-in MCP server. When it is connected to your AI client, drive the same inspect -> edit -> run/verify -> playtest ladder through its tools instead of manual clicking. This is OPTIONAL: when it is not connected, the manual Studio + Rojo workflow above and below is the full default path, and nothing in this skill requires MCP, Assistant, or any other tool. Enable it in Studio under Assistant, then Manage MCP Servers, then "Enable Studio as MCP server" (it speaks MCP over stdio to the client).
Map the workflow onto the documented tools. Every call also takes a studio_id; use
list_roblox_studios to pick the target when several Studio windows are open.
| Ladder step | MCP tools |
|---|---|
| inspect / inventory | search_game_tree, inspect_instance, script_search, script_grep |
| edit | script_read, multi_edit (creates the script when the path is new) |
| run / verify | execute_luau (needs a datamodel_type: Edit, Client, or Server), get_studio_state, start_stop_play, get_console_output, screen_capture |
| playtest | subagent (types explore, playtest), character_navigation, user_keyboard_input, user_mouse_input |
| Roblox's own docs/skills | http_get (allowed Roblox doc URLs), skill (Roblox-authored reference) |
The discipline does not change with MCP: multi_edit still writes normal, inspectable Scripts
(not a feature hidden in runtime construction), the server stays authoritative, you still edit
source-of-truth files rather than generated output, and you still clean up experiments. Treat
get_console_output and screen_capture as the agent-native evidence for the verification
ladder, and still inspect BOTH server and client output. MCP is a transport for the same
workflow, not a licence to skip it.
Roblox also ships agent-readable docs independent of MCP: an index at
https://create.roblox.com/docs/llms.txt and a .md twin of every docs page (append .md
to its URL). A connected client can reach these through http_get/skill; an offline agent
reads the .md pages directly.
Use the smallest rungs that cover the change, but never substitute a lower rung for a claimed higher-rung result.
| Symptom | Likely cause | Remedy |
|---|---|---|
| Studio edit disappears after sync | generated/mapped subtree edited | change source-of-truth files and resync |
| feature runs twice | duplicate Script/remote/controller | inspect first; consolidate under existing owner |
| client cannot access module/object | wrong execution/storage location | move shared content deliberately; keep secrets server-only |
| authored screen unreadable in Explorer | everything created by one LocalScript | create named Instance shell and small behavior modules |
| test passes only in Play | replication/lifecycle untested | use Server & Clients and relevant emulators |
| “clean” Output hides client errors | only server Output inspected | inspect each client and server context |
| shipped place has DebugFolder/prints | experiment cleanup skipped | maintain cleanup list and inspect hierarchy after session |
| Attribute/tag behavior silently fails | schema/class not validated | validate at setup boundary; warn with full Instance path |
references/studio-verification.md before reporting Studio validation or when choosing test
modes, constructing a temporary harness, or documenting an automation gap.roblox-luau — services, Instances, events, and basic execution model.roblox-ui, roblox-networking, roblox-characters, roblox-physics — focused production
workflows that use this inspection and verification discipline.https://create.roblox.com/docs/studio/testing-modeshttps://create.roblox.com/docs/projects/data-modelhttps://create.roblox.com/docs/scripting/serviceshttps://create.roblox.com/docs/studio/mcpNo reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Implement reusable decision systems for game characters using behavior trees, which organize conditional actions, and Utility AI, which scores available choices. Build either approach or combine them to control patrols, combat, targeting, and needs-based behavior.
Design game audio with grouped volume controls, music that responds to gameplay, and varied sound effects. Plan how music lowers during dialogue and how events follow the beat, using principles that can be adapted to different game engines.
Build and debug Rust games in Bevy using ECS, a way to separate game data from behavior. Organize apps and plugins, query entities, control execution order, and fix conflicting data access or frame-dependent movement.
Build and tune game cameras for smooth 2D following and 3D viewing. Covers motion smoothing, look-ahead, level boundaries, wall avoidance, and framing multiple targets, with techniques that apply across engines.
Design the core rules of a card game, including decks, hands, discards, drawing, shuffling, turns, and resource costs. Represent card effects as data and define their resolution order so card movement and gameplay outcomes follow explicit rules.
Plan and prepare consistent game artwork, from sprites and backgrounds to UI icons and 3D briefs. Organize asset requirements, generate or source related visuals, standardize files, and check their appearance and technical fit inside the game.