agentsclimarketplace

Roblox rojo

Skill nonlooped/roblox-suite/roblox-rojo

Stop shipping outdated Luau. Production-grade, opinionated skill set for AI agents and developers. Accurate Roblox guidance + reusable scripts, grounded in official docs.

Install
npx -y skills add nonlooped/roblox-suite --skill roblox-rojo

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 9 stars9 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Rojo project management for Roblox — install the CLI and Studio plugin, init/serve/build/upload/sourcemap/syncback, `.project.json` format, file-to-instance sync rules (`.luau`/`.server.luau`/`.client.luau`/`.plugin.luau`), meta files, `emitLegacyScripts`, live-sync limits, and porting existing places. Use when setting up Rojo, writing project files, live-syncing to Studio, building places/models, or converting a place with syncback.

SKILL.md

11.0 KB, as published. Nobody here has run it

roblox-rojo

Official sources (always check these for the latest):

Rojo maps a filesystem project to Roblox instances so you can edit with external tools (VS Code, Git, linters, formatters) and live-sync or build into Studio/place files. This skill covers Rojo 7 as documented at rojo.space and implemented in the current rojo-rbx/rojo release line.

When to use this skill

Activate when the user is:

  • Installing or upgrading Rojo (CLI, Studio plugin, VS Code extension, Rokit).
  • Creating a new place/model/plugin project (rojo init).
  • Writing or fixing .project.json / .project.jsonc trees.
  • Live-syncing with rojo serve + the Studio plugin.
  • Building places/models (rojo build) or uploading (rojo upload).
  • Generating sourcemaps for Luau LSP (rojo sourcemap).
  • Porting an existing place (rojo syncback, rbxlx-to-rojo, Lune).
  • Choosing script naming (.server.luau vs .client.luau vs modules) or emitLegacyScripts.

Cross-reference:

Mental model

PieceRole
Rojo CLIReads the project file + filesystem; serves live sync, builds place/model files, uploads, sourcemaps, syncback.
Studio pluginConnects to the local serve session and applies patches into the open place.
Project file*.project.json / *.project.jsonc describing the instance tree and options.
Filesystem treeScripts, models, JSON/TOML/YAML/CSV/text under $path nodes become Instances.

Rojo is filesystem → Studio for live sync (one primary direction). Optional two-way sync in the plugin is experimental and incomplete — do not design production workflows around it. For place → files, use rojo syncback (Rojo 7.7+) or external porting tools.

Quick start (correct order)

  1. Install the CLI (Rokit recommended for projects; GitHub binaries or cargo install rojo --version ^7 also supported).
  2. Install the Studio plugin with rojo plugin install (or GitHub rbxm / Roblox.com plugin for the matching major).
  3. rojo init my-game (or open folder + VS Code “Rojo: Open Menu”).
  4. rojo serve in the project folder.
  5. In Studio: open the Rojo plugin panel → Connect.
  6. Edit files on disk; watch them sync. Use rojo build -o build.rbxlx for a one-shot place file.

Full install matrix and CLI flags: references/installation-and-cli.md.

Script file → Instance mapping (defaults)

Both .lua and .luau are supported. Default rules (from Rojo source / sync docs):

File patternInstance (when emitLegacyScripts is true, the default)Instance (when emitLegacyScripts is false)
*.server.lua(u)Script (legacy RunContext)Script with RunContext = Server
*.client.lua(u)LocalScriptScript with RunContext = Client
*.plugin.lua(u)Script with RunContext = Pluginsame
other *.lua(u)ModuleScriptsame

Init usurpers (replace the parent folder with a script): init.server.lua(u), init.client.lua(u), init.plugin.lua(u), init.lua(u). Only one init script type per folder. A directory with default.project.json / default.project.jsonc is treated as a nested project instead of a plain folder.

Other defaults: .rbxm/.rbxmx models, .model.json(c), plain .json(c) → ModuleScript returning a table, .toml / .yml/.yaml similarly, .csvLocalizationTable, .txtStringValue.

Details, meta files, limitations: references/sync-details.md.

Project file essentials

Minimal place-shaped tree (services inferred without $className for known services):

{
  "name": "MyGame",
  "tree": {
    "$className": "DataModel",
    "ReplicatedStorage": {
      "$path": "src/ReplicatedStorage"
    },
    "ServerScriptService": {
      "$path": "src/ServerScriptService"
    },
    "StarterPlayer": {
      "StarterPlayerScripts": {
        "$path": "src/StarterPlayerScripts"
      }
    }
  }
}

Important top-level fields (docs + current CLI):

FieldPurpose
nameProject/instance name (optional for default.project.json — folder name used).
treeRoot instance description (required).
servePortDefault port for rojo serve (default 34872).
serveAddressDefault bind address when CLI --address omitted.
servePlaceIds / blockedPlaceIdsAllow/deny live-sync targets by place ID.
placeId / gameIdSet Studio place/universe IDs on connect.
serveAllowedHostsExtra Host/Origin values for serve (hostname access); CLI --allowed-hosts overrides.
globIgnorePathsGlobs to ignore (gitignore-style negation supported in recent releases).
emitLegacyScriptsDefault true = Script/LocalScript; false = RunContext Scripts for server/client files.
syncRulesCustom file→middleware patterns.
syncbackRulesControls rojo syncback behavior.

Instance nodes use $className, $path, $properties, $attributes, $ignoreUnknownInstances, plus child keys. Prefer implicit property syntax. Full format: references/project-format.md.

Daily commands

# New project (place | model | plugin)
rojo init my-game
rojo init --kind model
rojo init --kind plugin --skip-git

# Live sync (default localhost:34872)
rojo serve
rojo serve --port 34872 --address 127.0.0.1

# Build place/model
rojo build -o build.rbxlx
rojo build -o build.rbxl
rojo build --plugin MyPlugin.rbxm
rojo build -o out.rbxlx --watch

# Sourcemap for editor tooling
rojo sourcemap --output sourcemap.json
rojo sourcemap --watch --absolute

# Upload (prefer dedicated deploy account; never commit cookies/keys)
rojo upload --asset_id PLACE_ID --cookie "..."
rojo upload --asset_id PLACE_ID --api_key "..." --universe_id UNIVERSE_ID

# Place file → filesystem into an existing project tree
rojo syncback . --input place.rbxl
rojo syncback . --input place.rbxlx --dry-run --list

# Plugin management / docs / format
rojo plugin install
rojo plugin uninstall
rojo doc
rojo fmt-project

Live-sync limitations (do not ignore)

Not all property types apply in real time (Studio plugin API limits). Common cases that may need a full build + open instead of live sync:

  • Binary data (Terrain, CSG)
  • MeshPart.MeshId
  • HttpService.HttpEnabled

Property type coverage for build vs live sync is documented on the Properties page and rbx-dom’s coverage chart. When live sync fails for a class/property, rebuild with rojo build and open the place.

rojo serve binds to loopback by default. Binding to a network-reachable address exposes the session: recent Rojo versions validate Host/Origin, gate some APIs to local clients, and warn on non-local binds. Prefer localhost; if you must expose, use serveAllowedHosts / --allowed-hosts deliberately.

Porting existing games

  1. Refactor Studio code into fewer service-rooted locations (ReplicatedStorage, ServerScriptService, StarterPlayer, tags via CollectionService) before porting.
  2. Prefer rojo syncback with a project that already lists the services/paths you want filled (rojo syncback path/to/project --input place.rbxl). Only descendants of nodes present in the project tree are written.
  3. Alternatives called out in official docs: rbxlx-to-rojo, Lune for custom pipelines.
  4. Leaving Rojo is always possible: Rojo builds normal place/model files; you can stop using the filesystem tree and edit in Studio only.

Workflows and syncback rules: references/workflows-and-syncback.md.

Agent checklist (do this, not that)

  • Do pin CLI + plugin to the same major (Rojo 7 plugin with Rojo 7 CLI).
  • Do run rojo plugin install after upgrading the CLI.
  • Do put shared modules under ReplicatedStorage paths and server authority under ServerScriptService.
  • Do use .luau (Rojo’s init templates use .luau since 7.4).
  • Do set emitLegacyScripts: false only when the team understands modern RunContext scripts (and that client files become Script+Client, not LocalScript).
  • Do not invent CLI flags or project keys — if unsure, run rojo --help / rojo <cmd> --help or re-check docs/changelog.
  • Do not commit .ROBLOSECURITY cookies or Open Cloud API keys used with rojo upload.
  • Do not treat experimental two-way sync as reliable source control.
  • Do not confuse Rojo with Roblox Script Sync or Studio MCP — different tools; they can coexist (see roblox-mcp).

Verification

  • rojo --version reports a 7.x release matching the intended pin.
  • Studio shows the Rojo 7 plugin; connect succeeds against rojo serve.
  • Editing a .server.luau under a mapped $path updates the correct service in Studio.
  • rojo build -o build.rbxlx opens cleanly in Studio.
  • sourcemap.json is gitignored if generated (Rojo’s default gitignore template includes it in recent releases).

How to proceed

  1. Confirm install path: references/installation-and-cli.md.
  2. Shape the tree: references/project-format.md.
  3. Name files correctly: references/sync-details.md.
  4. For teams / porting / deploy: references/workflows-and-syncback.md.
<!-- catalog:references:start -->

Reference index

<!-- catalog:references:end -->

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.