Writing Effective Prompts

The quality of what Revix builds tracks the quality of what you ask for. This guide covers how to phrase requests so the AI gets it right the first time — whether you're generating a Luau script, building UI, or refactoring half your game.

The anatomy of a good prompt

A strong prompt answers three questions:

What should exist when the AI is done?

Where does it live in your game (which service, which script, which instance)?

How should it behave, including the edge cases you care about?

Compare:

❌ "make a shop"

✅ "Create a shop GUI in StarterGui with a scrolling list of 3 items (Speed Coil 100 coins, Gravity Coil 250, Rocket 500). Buying should fire a RemoteEvent that a server script validates against the player's leaderstats Coins before granting the tool."

The second prompt produces a working, validated shop in one pass. The first produces a guess.

Be specific about locations

Revix can see your synced game tree, but naming things removes ambiguity:

❌ "fix the door script" → ✅ "fix the script inside Workspace.Dungeon.Door1 — it should only open for players with the Key tool"
❌ "edit the leaderboard" → ✅ "in ServerScriptService.Leaderstats, add a Rebirths stat that starts at 0"

If you don't know where something is, ask first: *"which scripts reference the DamageEvent RemoteEvent?"* — Revix will grep your game and tell you. See Searching Your Game.

One task per message

Each message should be one coherent task. Bundling unrelated asks ("fix the shop, also make a pet system, also why is lighting broken") splits the AI's attention and makes failures hard to untangle. Three focused messages finish faster and cleaner than one tangled one.

Big single tasks are fine — "build a round-based sword fighting game loop" is one task. Revix will break it into a checklist and work through it step by step (AI Checklists & Long Tasks).

Describe behavior, not implementation (usually)

You don't need to know Luau to use Revix. Describing the player experience is enough:

"When a player touches the lava, they should die, respawn at the last checkpoint they touched, and keep their coins."

But if you *do* have implementation opinions, state them — the AI will follow:

"Use a single RemoteEvent with an action string instead of one RemoteEvent per shop item. Validate everything server-side."

Iterate instead of restarting

Revix keeps the conversation in context. After a build, refine it with short follow-ups:

"Make the buttons bigger and move the close button to the top right."
"Now add a purchase cooldown of 2 seconds."
"That broke the coin counter — fix it."

If a result is badly off course, it's often faster to undo (every AI change is wrapped in a Studio undo waypoint — see undo) and re-prompt with more detail than to steer a bad build sentence by sentence.

Give error messages verbatim

For debugging, paste the exact error from the Output window, including the line number:

"Players.Kai.PlayerGui.ShopGui.LocalScript:23: attempt to index nil with 'Coins' — fix this."

The real error beats any paraphrase. If there's no error but wrong behavior, describe what you expected vs. what happened.

Use the right model for the prompt

Short, well-scoped prompts run great on the Standard model. Architecture-heavy prompts ("design and build a trading system with server validation and DataStore persistence") deserve Revix MAX. See Picking the Right Model for the full decision guide.

Prompt patterns that work well

Goal	Pattern
New feature	"Build [feature] in [location]. It should [behavior]. Handle [edge case]."
Bug fix	"[Paste exact error]. It happens when [trigger]. Fix it."
Refactor	"Refactor [script/system] to [goal] without changing behavior."
UI	"Create a [style] UI for [purpose] with [list of elements]. Parent it to [location]."
Explore	"Explain how [system] works in my game" / "Where is [thing] handled?"
Big build	"Plan and build [system]. Ask me anything unclear before starting."

For a library of ready-made prompts you can copy, see Example Prompts.