# Roblox Luau Developer

> Roblox Luau development — implement, review, and refactor Luau gameplay scripts; diagnose Roblox gameplay, replication, performance, DataStore, and runtime issues; and understand or sync Rojo-managed Roblox codebases. Use when working on Roblox, Luau, Roblox Studio code, or Rojo projects, or when debugging Roblox runtime issues.

- Skill: `demon673/roblox-luau-developer` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add demon673/roblox-luau-developer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/demon673/roblox-luau-developer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: demon673 (https://skillmd.com/u/demon673)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/demon673/roblox-luau-developer

---


# Roblox Luau Developer

Workflow for implementing, reviewing, and refactoring Roblox Luau code, diagnosing runtime issues, and syncing Rojo-managed codebases. Assumes Luau and the Roblox server/client model; does not assume a project uses Rojo or TypeScript.

## Identify the project shape

First determine how the project is organized:

- Rojo project: a `default.project.json` or `*.project.json`; the toolchain files and sync workflow live in `references/rojo-workflow.md`.
- Studio export: recognize `.rbxlx`, `.rbxmx`, `.model.json`, `src/`, `ReplicatedStorage/`, `ServerScriptService/`.
- TypeScript source: a `roblox-ts` project carries `tsconfig.json`, `rbxtsc`, and `@rbxts/*` packages; treat its `.ts` source as the source of truth and do not patch generated Luau under `out/`.

## Read before editing

- Search services, modules, Remote names, Attribute names, and CollectionService tags with `rg`.
- Map the call direction of ServerScripts, LocalScripts, and ModuleScripts.
- Do not invent Instance paths, Remote names, or UI control names.

## Keep the server/client layering

- Authoritative state and validation live on the server.
- The client handles input, display, prediction, and requests.
- Remote parameters must be type- and permission-checked.
- DataStore writes need throttling, retries, and failure handling.

## Prefer small changes

- Preserve an existing module's return shape, service names, and require style.
- Avoid implicit global state in public modules.
- Provide a cleanup path for shared tables and connection objects.

## Debugging

For runtime, replication, performance, DataStore, and UI-not-updating issues, follow the playbook in `references/gameplay-debugging.md`.

## Rojo projects

For understanding, maintaining, and syncing a Rojo-managed codebase, follow `references/rojo-workflow.md`.

## Verify

- Prefer existing checks: `selene`, `stylua`, `luau-lsp`, `lune`, `rojo`, or project scripts.
- If only static analysis is possible, say explicitly that no Studio / Play Solo run happened.

## Output

- Changes: which scripts and behavior changed.
- Server/client boundary: where authoritative logic lives.
- Remote/DataStore risk: interfaces added or changed.
- Verification: checks actually run; note when Studio cannot run.

