CreatiCode XO - Prompt Clinic

CreatiCode

Introduction

To help you learn to improve your prompting skills, we have developed a new tool called “Prompt Clinic”. Whenever you submit a message to XO, either in the chat or agent mode, we would give it a score and provide some feedback on how well that prompt is written.

The Rating Scale

Your prompts may get a score between 1 and 5. Below is the rules used to determine the score:

Poor Prompts Are Blocked

When your prompt is given a score of 1, it will be automatically blocked. That is, it will not be sent to the XO server for a response. For prompts with a score of 2 to 5, they will be sent to XO as usual.

When this happens, don’t just wait for XO to respond, since it will not see your prompt. You can click the continue anyway button to force the agent to respond, but we strongly recommend you to send a new request that is clearer and more detailed.

Pro Techniques

There are some commonly used prompting techniques that would normally lead to much better results if you used them well. They are listed below for your information.

Assign a role

One of the easiest ways to get a sharper answer from XO is to tell it who it should be when it replies. Large language models know a lot about almost every subject, but they answer more precisely when you pin them to a specific perspective. Without a role, XO tends to give generic, middle-of-the-road answers. With a role, it pulls from the vocabulary, habits, and typical concerns of that expert.

In Creaticode, a role is especially useful when your question sits on the edge of a specialty — physics, game design, art, storytelling, data, or teaching younger kids. Picking a role nudges XO to use the right words and think about the right trade-offs.

Examples you can try:

“Act like a game designer. Review my platformer project and tell me which parts feel too easy or too hard.”
“Pretend you are a physics teacher explaining to a 12-year-old. Why does my falling ball sprite look so floaty compared to real life?”
“You are an experienced Creaticode mentor. Look at my script on the Cat sprite and point out any blocks that are redundant.”
“Act like a children’s book writer. Help me rewrite the dialogue on my Wizard sprite so it sounds more magical.”

Notice that the role can be a profession (teacher, designer), a skill level (mentor, beginner), or a personality (strict reviewer, friendly coach). Pick whichever best matches the kind of answer you need.

Give a worked example

A worked example shows XO exactly what shape of answer you want. Instead of describing the output in words (“give it a nice format”), you show one or two finished samples and ask XO to continue the pattern. This is much more reliable because words like “nice” or “clear” mean different things to different people, but a concrete example can only be read one way.

This technique is particularly helpful when you want a list of items, a naming scheme, dialogue lines, or formatted data.

Examples in Creaticode:

“I want to rename my sprites in a consistent way. Here’s the pattern I like: Player_Cat, Enemy_Dog, Item_Apple. Please suggest names for the rest of my sprites following this pattern.”
“Give me 5 new enemy names for my space game. Here are two I already made so you match the style: Zogra the Pink Blob, Krix the Floating Eye.”
“Make my Cat sprite say funny lines when it loses. Example tone: ‘Oof, gravity won this round.’ or ‘Note to self: jumping ≠ flying.’”
“I want score messages. Examples: Score 10 → 'Nice start!', Score 50 → 'You're on fire!'. Now give me messages for 100, 200, and 500.”

You don’t need many examples — two is usually enough. The more unusual your style, the more useful it is to show examples.

Provide reference data

Never make XO guess numbers, names, or error messages when you can paste them in directly. Paraphrasing (“the error said something about undefined”) forces XO to guess, and guesses are often wrong. Real data shuts down the guessing and lets XO focus on solving the actual problem.

This matters a lot in Creaticode because the details are often exactly what determines the bug.

Examples:

Block names: Instead of “I used the move block”, say “I used move 10 steps” so XO knows whether the issue is with movement amount or direction.
Variable values: Instead of “the score is wrong”, say “after 3 enemies are defeated, score = 2, but it should be 3.”
Stage coordinates: Instead of “the sprite is in the wrong place”, say “the Cat sprite should land at x=120, y=-80 but ends up at x=120, y=-40.”
Error or console output: Paste the exact red message you see. A single digit or color value can change the whole diagnosis.
Costume or sound names: Say “my Cat has costumes cat-idle, cat-run-1, cat-run-2” so XO knows the exact names to reference in the code it writes.

Think of it this way: XO can read anything you put into the chat, but it cannot see your project for free. Every concrete number or name you paste is one less thing it has to guess.

State expected vs actual

“It doesn’t work” is one of the hardest prompts for XO to answer, because it has no idea what “work” even means to you. The fix is to split your description into two parts: what you expected, and what actually happened. This turns a complaint into a diagnosable report.

When XO has both pieces, it can jump straight to comparing them and looking for the cause of the difference.

Examples in Creaticode:

“Expected: When I press the space key, the Cat jumps up and slowly falls back down. Actual: The Cat jumps up but then stays in the air forever.”
“Expected: The score should go up by 1 each time the arrow hits a balloon. Actual: The score jumps by 3 every time, even with a single arrow.”
“Expected: The background should change from day to night after 10 seconds. Actual: It flickers between day and night every half-second.”
“Expected: My 3D ball should roll smoothly across the floor. Actual: It teleports from one end to the other without moving in between.”

This pattern works for art and story bugs too, not just logic:

“Expected: The Dragon sprite faces the direction it’s moving. Actual: It always faces right, even when flying left.”

If you can, add what you already tried as a third line — that saves XO from suggesting the same thing again.

Point out specific issues

When XO gives you code or an explanation and something is off, resist the temptation to just say “that’s wrong” or “try again”. Those prompts give XO no information — it has to guess what you didn’t like and usually guesses differently than what you meant. Instead, name the specific part that’s wrong and, if you can, say which direction to adjust.

This is a key skill because you will go back and forth with XO a lot. Clear feedback shortens the loop from ten tries to two.

Examples:

Not: “The jump is wrong.”
Better: “The jump is too fast. Slow it down by about half.”
Not: “The sprite looks weird.”
Better: “The Cat sprite turns upside-down when it walks left. It should face left instead of flipping.”
Not: “The code is wrong.”
Better: “The when space key pressed block should be on the Player sprite, not on the Stage. Please move it.”
Not: “That’s not what I meant.”
Better: “I only wanted the Dog sprite to bark when clicked — your code makes every sprite bark.”

The pattern is: what is off → how to adjust. Even pointing out just one of the two is much better than none.

Suggest a diagnostic action

Sometimes you and XO are both stuck — neither of you knows why the code misbehaves. Rather than guessing, you can tell XO to add a small piece of diagnostic code that will reveal what’s happening. This is what real programmers do when they debug.

A diagnostic action asks XO to insert something like a print statement, a log, or a temporary visual signal, and then report back what it shows.

Examples in Creaticode:

“My enemy sprite isn’t moving. Add a say block inside the forever loop that shows the x-position every second, so we can see if the x-value is changing.”
“My score variable seems broken. Make the score show in a say bubble every time an enemy is hit, including the new score value, so we know when it’s being updated.”
“The Ball sprite is supposed to bounce off walls. Change the Ball’s costume color briefly each time it touches an edge so I can see when the edge-detection fires.”
“The 3D character keeps falling through the floor. Add a text label above the character that shows its y-position, so I can watch the drop happen in real time.”

After XO adds the diagnostic, run your project, look at what appears, and report the values back. With real data in hand, XO can usually point at the real cause quickly.

Specify tone or audience

By default XO writes for a general programmer — which can be too technical if you’re new, or too childish if you’re advanced. You can reshape its answers by telling it who is listening and what voice you want.

This is especially useful for explanations, tutorials, and in-game dialogue.

Examples:

“Explain how the broadcast block works like I’m 10 years old, no code, just words.”
“Use very simple English. English is not my first language.”
“Write your answer like a patient tutor, not a lecture. Stop and ask me if I follow each step.”
“Explain this in one short paragraph only. Then I’ll decide if I need more.”
“Write the Wizard sprite’s lines in a playful, slightly spooky voice, like a friendly Halloween story for kids.”

You can also flip this for your own notes:

“Summarize what we built today like a changelog entry for a game dev blog.”

The more specific your tone request, the more XO’s output will match the vibe you want on the first try.

Ask for a plan first

When the task is big or complicated, don’t let XO jump straight to building. Asking for a plan first forces it to think through the pieces before writing code. You can read the plan, catch mistakes early, and correct course before any blocks are placed — which saves a lot of time compared to fixing a half-built project.

This is especially valuable in agent mode, where XO actually modifies your project.

Examples:

“I want to add a boss fight at the end of level 3. Before you build anything, list the steps you plan to take — what sprites, what blocks, what variables.”
“Help me turn this into a two-player game. First, outline what needs to change, sprite by sprite. Don’t touch the blocks until I say go.”
“I want the story to branch based on player choice. Tell me the structure first — which scripts, which broadcasts, which variables — then I’ll approve before you build.”
“Add a shop where the player can buy items. Give me a 5-step plan first.”

You can then iterate on the plan itself (“step 3 should come before step 2”, “I don’t want a new variable, reuse the existing coins”) and only proceed when you’re happy. This is often the single biggest quality boost for medium-to-large requests.

Set scope — positive and negative

XO sometimes does more than you asked for — helpfully refactoring sprites you didn’t mention, renaming variables, or tidying up scripts. To prevent surprises, tell it both what you want changed (positive scope) and what you explicitly do not want touched (negative scope).

This is especially important when you have work you’re proud of and don’t want disturbed.

Examples:

“Only change the jump height on the Cat sprite. Don’t touch its costumes, sounds, or any other sprites.”
“Update the score display to show two digits (e.g., 07 instead of 7). Don’t change how the score is calculated.”
“Add a new enemy called Slime. Don’t modify the existing Ghost enemy at all.”
“Rewrite the Player sprite’s movement code. Keep the collision blocks exactly as they are — they took a long time to tune.”

A useful phrase: “Everything else in the project must remain unchanged.” This tells XO clearly that the rest of the work is off-limits.

Request alternatives

If you want a design choice — not just a fix — ask XO for two or three options rather than a single answer. You can then pick the one that fits best, or mix ideas from several. This keeps you in the driver’s seat instead of accepting the first solution XO happens to produce.

Examples:

“Give me 3 different ways to make my Cat sprite jump — simple, realistic, and cartoony. Describe each in one sentence.”
“Show me 2 options for the level-complete sound. One heroic, one funny.”
“Suggest 2 ways to track the player’s lives — a variable with hearts drawn as sprite clones, or a costume-based heart bar.”
“Offer 3 names for my new racing game, each with a different vibe — fast, silly, epic.”

Getting options is a great way to learn, too. Seeing two solutions side-by-side teaches you more about trade-offs than seeing just one.

Ask the AI to self-check

After XO builds or explains something, you can ask it to review its own work. This often catches bugs or edge cases that XO would otherwise miss, because the act of reviewing uses a different kind of thinking than the act of building.

Think of it as asking XO to put on its QA hat after putting down its builder hat.

Examples:

“After you finish the jump code, tell me what could go wrong. What if the player presses space twice in a row? What if they press it in mid-air?”
“Once you add the score logic, list 3 edge cases I should test — like what happens if the score goes negative.”
“Now that you’ve built the dialogue tree, walk through it as if you are the player. Is there any path that leads to a dead end?”
“After rewriting the Boss sprite, double-check that it still respects the damage variable from earlier.”

Self-check questions lead to better final results because XO often spots issues and fixes them before you even have to run the project.

Ask the AI to ask first

Sometimes you’re not sure exactly what detail XO needs to do a good job. Instead of guessing and then revising, flip the conversation — tell XO to ask you the questions it needs answered before it starts. This works because XO usually knows better than you which missing details will most affect the result.

Examples:

“I want to build a rhythm game. Before you start, ask me any questions you need answered to build it well.”
“Help me design a boss for my platformer. What do you need to know from me first?”
“I want to translate the whole game to Spanish. Ask me clarifying questions before beginning — there might be names or puns you shouldn’t translate.”
“I want my game to feel ‘cozy’. Ask me questions to figure out exactly what kind of cozy — Animal-Crossing cozy, bedtime-story cozy, or campfire cozy.”

Answering three short questions up front is much faster than rebuilding after a misunderstanding.

Give a negative example

Sometimes describing what you don’t want is easier than describing what you do. A negative example can instantly rule out a wide family of solutions and point XO toward the right neighborhood.

This technique is especially useful for art direction, style, and game feel.

Examples:

“I want a movement system not like a platformer — more like a top-down adventure game, where the player can move in all four directions freely.”
“Make the villain sound threatening but not like a cartoon. No ‘mwahaha’. More like a quiet, calm danger.”
“Design the UI not like a kids’ app — I want clean, modern, minimal. Think sports watch, not cereal box.”
“Give me a jumping sound not bouncy, not squeaky — more like a quick, solid thud.”
“Not a number — I want the score shown as stars filling up a row.”

Combining a negative example with a positive one (“not X, more like Y”) is an even stronger prompt.

Work in small steps

Big requests often lead to big, messy results. If you ask XO to “build a whole RPG” in one shot, it will skip details and make many choices you might disagree with. Instead, split the work into small steps, confirm each one, and only then move on.

This is how experienced programmers build anything non-trivial — it’s not a shortcut, it’s the real method.

Examples:

“Step 1 only: Make the Cat sprite move left and right with arrow keys. We’ll add jumping after.”
“First, just set up the enemy sprite and give it a costume. Don’t add movement yet.”
“Let’s build the save system in stages. Today, only save the player’s score. Next time we’ll add inventory.”
“Build the title screen first. Once I approve it, we’ll move on to the menu and then the gameplay.”

An added benefit: if something breaks, you’ll know it was introduced in the most recent small step, which makes debugging much easier.

Set success criteria

Before XO builds something, agree on how you’ll know it’s done. Without a clear finish line, XO may keep adding features you didn’t ask for, or stop too early and miss something important. A success criterion is a short description of the final behavior you’re aiming for.

Examples:

“The task is done when the score reaches 10 and a celebratory ding plays.”
“This is finished when the Ball sprite bounces off every wall of the stage without getting stuck.”
“Done means the player can beat the level without ever touching an enemy, and if they do touch one, they respawn at the start.”
“Success = all 5 Mushroom sprites show up in random positions at the start of each game, and none overlap.”
“I’ll call it done when every dialogue line fits in one say-bubble without being cut off.”

Writing the success criterion forces you to think about exactly what you want, which is half the work of getting a good answer.

Show your attempt

If you’ve already tried something and it didn’t work, tell XO what you tried and what went wrong. This prevents XO from suggesting the same thing again and often helps it jump straight to the real cause.

It also signals that you’ve done some thinking, which shifts the conversation from “explain from scratch” to “help me debug my current approach.”

Examples:

“I tried the glide 1 sec to x: 100 y: 50 block, but the Cat snaps to the destination instantly instead of moving smoothly. What am I missing?”
“I added an if touching Enemy inside a forever loop. The Cat takes damage correctly, but then the game freezes for a second before continuing. I suspect something about loop timing.”
“I already tried using a variable called jumping to track mid-air state, but the Cat sometimes double-jumps anyway. I don’t understand why.”
“I used broadcasts to switch scenes, but the background music from scene 1 keeps playing during scene 2. I tried stop all sounds, but then the scene-2 music won’t start either.”

A short “here’s what I did, here’s what broke” is one of the fastest ways to get high-quality help — and it’s exactly how real developers ask each other for help too.