Luau patterns I keep re-explaining to my AI assistant (and how I stopped)

If you use Claude or ChatGPT to write Luau in Roblox Studio, you have probably corrected the same mistakes more than once.

Invented APIs are the obvious one. The quieter failures are architectural: a ModuleScript treated as shared memory between client and server, a RemoteEvent that trusts the client, wait() and spawn() copied from old Lua tutorials, connections that leak when a character respawns, a second DataStore wrapper because yesterday's chat is gone.

I got tired of teaching these in every new session. The fix was not a longer system prompt. It was a short patterns file that lives outside the chat, plus a rule that the assistant has to follow it or say it is uncertain.

1. The client is a request, not a source of truth

A RemoteEvent fired from the client can claim anything: "I bought this item," "I dealt 999 damage," "give me the reward." The server has to decide.

Check that the player can actually afford it, that the item exists, that the cooldown has elapsed, that the character is in a state where the action is legal. Then apply the result on the server and replicate it back.

This is standard Creator Hub security guidance, and it is still the first pattern models drop when you ask for "a simple shop." I keep a one-line rule in the patterns file: client input is a request; the server validates and writes state. If a generated shop script awards currency on the client, it is not done.

2. ModuleScripts are not a shared database

A ModuleScript required on the server and required on the client is two separate copies. Mutating a table in one does not update the other. Shared state belongs in the DataModel - attributes, value objects, instances - or it is sent through remotes.

I have watched models "fix" a desync by stuffing more fields into a module that only one side can see. The bug looks like a timing issue. It is a memory-model issue. The patterns file says so in one paragraph, because I was tired of diagnosing it as if it were new.

3. Prefer the task library

Old Lua tutorials still teach wait(), spawn(), and delay(). In Luau, new code should use task.wait, task.spawn, and task.delay (and task.defer when the work should run after the current resumption).

This is not a style preference. The deprecated globals are less predictable, especially under load, and they keep reappearing because training data is full of them. My rule is mechanical: new code uses the task library; if you see wait(), replace it. I do not want a debate about it in the middle of a shop script.

4. Clean up connections

Characters respawn. Tools get unequipped. UI is destroyed and created again. A connection on Humanoid.Died or a RenderStepped loop that is never disconnected will pile up. The script may "still work" for five minutes and then stutter.

I ask the assistant to disconnect, or to use a Maid/Janitor-style helper, and to treat "this still runs after Destroy" as a bug. "I'll leave the connection, it is fine" is not an acceptable close to a task.

5. Do not invent APIs - and do not silently upgrade them

If a service method, property, or enum is not in a project note with a source and a date, the assistant must look it up or mark it uncertain. It may not invent MarketplaceService:PromptSomething(), and it may not "modernize" a working call because a 2019 blog post used a different name.

This rule alone cuts the paste-error-apologize loop. A confident paragraph about an API that does not exist looks identical to a verified one. The pattern is: cite, or say "uncertain" and how to check in Studio.

6. One module, one job - do not open a second shop

Before writing a new currency, inventory, or save path, the assistant reads the current project status and the code index. If a DataStore wrapper already exists, extend it. Duplicate systems are how a weekend project becomes two games in one folder.

This is the architectural twin of the invented API: not a wrong method name, but a second source of truth. Both come from a chat that has no memory of yesterday.

How I stopped re-explaining all of this

I keep a luau-patterns.md (the name does not matter) in a project vault, next to a short status.md for the game I am actually building. The patterns file holds the six rules above and a few snippets I have already run in Studio.

The master prompt is short: read the patterns and the current status first; do not invent APIs or numbers; do not call a task done without a playtest; when uncertain, say so and how to check. After a session I add one line - exact error, cause, fix - even if the session was aborted.

I still have to playtest, including on a phone-sized viewport. A patterns file will not catch a jump that is unusable on touch. It just stops me from teaching the same six rules to a blank chat every morning.

If you want this structure ready-made I packed this working method into a German-language kit called Roblox Second Brain: a copy-paste master prompt, a 292-page knowledge base (PDF and Markdown, dated 31 October 2026), setup notes, a Luau course, genre blueprints, and an Obsidian-friendly vault with the before/after routine above. It is 19 € once. There is no success claim, and it is not an official Roblox or Anthropic product.

A free sample - 12 patterns shared by many hit games, a second-by-second first-minute plan, and a 30-day zero-budget launch template - is here: https://whop.com/kelvaro-creator-kits/leseprobe-roblox-second-brain

The full kit is here: https://whop.com/kelvaro-creator-kits/roblox-second-brain

Launch offer: code LAUNCH40 = 40 % off, for the first 10 buyers only, until 16 November 2026.

Disclosure: the linked kit is my own paid product. The sample is free. I am not affiliated with Roblox Corporation or Anthropic.