Getting Great Results
Roflow does its best work when your request is clear, well-scoped, and backed by the right context — this page shows you how to ask so you get what you had in mind on the first try.
The short version
If you remember nothing else, remember these four habits:
- Be specific. Say what to build, where it lives, and how it should behave.
- Give context. Point Roflow at the files, images, or examples that matter.
- Describe the outcome. Tell Roflow what "done" looks like so it can check its own work.
- Review as you go. Read the changes, keep or reject them, and steer with your next message.
Everything below expands on those four. None of it is about clever wording tricks — it's just about telling Roflow clearly what you want, the same way you'd brief a teammate.
Be clear and specific
The single biggest factor in a good result is a specific request. A vague ask forces Roflow to guess at the details you left out; a clear one tells it exactly what to build.
The difference is almost always in the specifics — what, where, and how it behaves:
| Vague request | Clearer request |
|---|---|
| "Add a shop." | "Add a shop UI in the top-right that sells three speed upgrades for coins, with prices 100 / 250 / 500." |
| "Make a tycoon." | "Build a tycoon with a dropper, a conveyor, a collector pad, and a purchase pad that upgrades the dropper. Track Cash in leaderstats." |
| "Fix the coins." | "Coins reset to zero when a player rejoins. They should save and reload with the player's data." |
| "Add saving." | "Save each player's Cash and owned upgrades so they persist across sessions, and load them when the player joins." |
| "Improve the UI." | "Make the currency HUD bigger and move it to the top-left, and match the blue color used in the shop screen." |
Notice that the clearer versions aren't longer for the sake of it — each extra phrase removes a decision Roflow would otherwise have to make for you.
On an existing game, the most useful detail you can add is location. Naming the file, folder, or system to change — or attaching it with @ — keeps Roflow from guessing and stops it touching the wrong thing.
Give Roflow the right context
Roflow builds best when it can see what you're talking about. Instead of describing your project in words, point it at the real thing. The composer gives you several ways to do this (the hint underneath sums them up: "Type @ for context, / for slash commands & workflows, hold shift to drag in files/images"):
- Reference files, folders, and more with
@. Type@or click Add Context to attach a File or Folder, the current Problems (errors and warnings), the Terminal contents, a Git commit, or a URL for Roflow to read. - Attach images. Click Add Files & Images, paste an image straight in, or drag one in while holding Shift. A screenshot or mockup often says more than a paragraph. The default Balanced model can read the images you attach.
- Pull in code from the editor. Select code and press Cmd/Ctrl+' (or right-click and choose Add to Roflow Agent) to drop it into the chat as context.
For the full walkthrough of each of these, see Talking to Roflow.
When you can point at an example — a screenshot of the UI you want, the file that has the pattern to copy, the error message to fix — do that instead of describing it. Concrete references produce far more accurate results than adjectives.
Let Roflow learn your project first
On a game you already have, run /init before asking for new features. Roflow inspects your project, asks a few questions, and learns your structure and conventions, so the work it adds fits what's already there instead of fighting it. After setup it keeps a plain, editable ROFLOW.md overview of your game that future tasks load automatically — so you don't have to re-explain the whole project every time. See Existing Projects.
Save rules for things you always want
If there are conventions you want Roflow to follow every time — naming styles, folder layout, a coding preference — you can save reusable project rules so it applies them consistently without you repeating yourself in each message.
Describe the outcome you want
Tell Roflow not just what to do, but what a good result looks like. When you describe the finished state, Roflow has something concrete to build toward — and, when Studio is connected, something to check its own work against.
A few ways to frame the outcome:
- State the behavior. "When a player steps on the pad, their Cash goes up by 10 and the dropper speeds up" is a target Roflow can verify. "Make the pad better" is not.
- Name the acceptance test. "I should be able to buy the upgrade, rejoin, and still have it" tells Roflow exactly what to playtest.
- Call out constraints. "Keep it server-authoritative," "don't change the existing save format," or "match the art style in the lobby" narrow the solution before Roflow starts.
When Roblox Studio is connected, Roflow verifies its own work — it takes a screenshot of the viewport, reads the console for errors, and runs a short playtest to confirm the game actually behaves as asked. The clearer your description of "done," the more meaningfully it can check. If Studio isn't connected, it can still edit files but will flag that it couldn't verify visually. See Playtesting.
Ask for one thing at a time
A whole game is many systems, and asking for all of them in one message is where results most often go wrong. Smaller requests are easier for Roflow to get right and easier for you to review and test.
A good rule of thumb: a request is the right size if you could playtest it and say whether it worked. Build the core loop first, get it playable, then layer on a shop, then saving, then polish — one request per stage. See Building in Stages for worked examples.
Plan first for anything big
For a large or ambiguous request, agree on the approach before any code is written. In Plan mode, Roflow reads your project and proposes an approach without changing anything; you refine it in plain language, then switch to Act mode to build. For a feature that would normally need a design doc, /deep-planning has Roflow investigate, ask targeted questions, and produce a reviewable plan first.
Planning up front catches a misunderstanding while it's still a sentence — not after a hundred lines of code. See Planning Your Game.
Review changes as you go
Getting a great result is a conversation, not a single perfect message. Roflow is built around this: by default it asks before it acts, so you see every change before it lands.
- Read the diffs. When Roflow wants to create or change a file, it shows the change first. Click Apply to accept it or Reject to discard it. Commands prompt Run Command / Reject; other actions prompt Approve / Reject.
- Answer its questions. When Roflow needs a decision it shows a "Waiting on you" card with clickable options. Picking the right one early keeps it on track.
- Course-correct immediately. If an edit isn't what you wanted, reject it and say what to do differently in your next message — you don't have to accept something and fix it later.
Rejecting a change and explaining what's off is one of the best ways to steer Roflow. It revises and proposes again with your feedback in mind, so a quick "reject + reason" is often faster than accepting and patching.
Iterate without starting over
When you want to change direction, you don't have to begin from scratch:
- Keep talking. After a change lands, reply with the next adjustment — "make the HUD bigger," "the coins still aren't saving." Roflow keeps your game's context across the task.
- Edit an earlier message. Click one of your own earlier messages, edit it, and resend. Restore Chat rolls the conversation back to that point while leaving your files as they are; Restore All rolls back both the conversation and your workspace files, so you can try a completely different approach from a clean start.
- Undo with checkpoints. Roflow snapshots your workspace as it goes, so you can compare what changed and restore to an earlier point at any time. This is your safety net for experimenting — and what makes it comfortable to loosen auto-approve while prototyping.
Two tools that help you ask well
- Improve prompt. Not sure your wording is clear? Click the sparkle Improve prompt button and Roflow rewrites your draft into a stronger version, showing a before/after view. Nothing changes silently — you explicitly Accept the rewrite or Cancel to keep your original.
- The right model for the job. The model button in the composer offers Fast (quick edits), Balanced (the all-round default, which can read images), and Max (most capable, for complex reasoning and debugging). Reach for Max on a hard, multi-step problem; stay on Fast or Balanced for routine edits. Higher tiers draw down more of your monthly usage — see Usage.
A quick checklist
Before you send a request, a fast gut-check:
| Ask yourself | If not… |
|---|---|
| Did I say what to build, where, and how it behaves? | Add the missing specifics. |
| Does Roflow have the files/images it needs? | Attach them with @ or the file button. |
| Would I know if it worked? | Describe what "done" looks like. |
| Is this one reviewable step, or ten? | Split it into stages. |
Where to go next
- Talking to Roflow — the full guide to making requests, giving context, and approving changes.
- Building in Stages — sequencing a whole game into buildable steps.
- Common Pitfalls — the mistakes that lead to poor results, and how to avoid them.
- Planning Your Game — Plan mode and deep planning for bigger asks.
- Existing Projects — bringing Roflow into a game you already have.
- Playtesting and Fixing Issues — checking and correcting each change in Studio.