china users

@regis

This issue is resolved now. Please test again.

@regis

This block is available now. Please give it a try!

@试员期测测啊

This issue is fixed now.

@regis

This is an interesting idea. We’ll add it. Thank you

@案的那瓦他嘛

你能发个项目链接吗？我们看看是什么问题？

@regis

Can you please share the project?

Introduction

 
Coding agents like Claude Code or Codex have been drastically changing how computer programmers work over the past year, and will continue to do so. They can write code much faster than human programmers, and they even enable people who don’t know coding to create apps and websites by simply describing them with words - so called “vibe coding”.

At this point of time, no one can predict what software engineering looks like in 10 years, or how AI would transform other types of jobs. However, it is pretty obvious that everyone would be using AI agents as part of their work, so it is an important skill for every student to pick up.

Today, we are introducing a new “agent mode” for the XO AI assistant. In this mode, XO would not just “chat”, but actually make changes to the assets or code blocks in your project directly based on your instructions, such as adding a background image or changing some code blocks. If you learn to use the agent mode well, you will not only build projects faster on CreatiCode, but also become more comfortable working with other agents for learning or work in the future.

 
 

Turn On/Off the Agent Mode

 
To use XO in the agent mode, you simply need to check this checkbox in the XO chat window, and your selection will be remembered. Uncheck it to return to the previous “chat-only” mode.

 
For teachers, you can enable or disable this feature for the class in the class management page:

 
 

Basics of Working with the XO Agent

 

When working with the XO agent, this is typically what would happen:

1. You start with a request to build something new or change an existing project;
2. The XO agent may ask you some questions to confirm/clarify what you want to do;
3. After the agent has gathered enough information, it will start working on the request, such as adding a costume (search in the AI image library or draw a new svg costume), adding a new sprite, adding code blocks to a sprite, changing some code blocks in a sprite, etc.
4. The agent will stop after completing a reasonable milestone, and ask you to review its work. You can ask it to change its work or continue to the next milestone. Of course, if your request is relatively small, it may finish all the work in one go.

The first and forth steps now become much more important, and they will require creativity, critical thinking and agency.

In addition, knowledge about coding is still very valuable. They will allow you to specify the task better and evaluate the agent’s work better.

 
 

Prompt Clinic Score

 

Every time you submit a message, it will be scored based on how well it is written. This is our “Prompt Clinic” tool that helps you improve prompting skills over time.

If the score is 1 (the lowest), that means your request maybe unclear or confusing, so it will NOT be sent to XO; if the score is 2 to 5, then the request will be sent to XO as usual (not blocked).

 
When the score is 1, 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.

Read more about the Prompt Clinic in this post.

 
 

Example Workflow - Create a Game

 

Below is a more concrete example of how you can work with the XO agent to build a simple game. It is just an example to give you some idea how it works, and when you use the agent yourself, it may behave very differently depending on how you prompt itt.

 
 

Step 1 - Turn On the Agent Mode

 

Create a new project, open the XO chat window, and turn on the agent mode. You can turn it off to return to the “chat” mode, or close the window using the “X” button at top right.

 
 

Step 2 - Submit a new request

 

Since we are starting from a blank project, make sure the agent knows what type of game you want to build, and provide enough information for it to get started (the more the better). If the game is kind of well known, then it should know what to build from the name, but if it is a more original game idea, then you need to provide more information.

For this example, we will start with this request: build a classic breakout game, with a few rows of breaks at top, and the player controls a paddle to bounce a ball up to break the bricks.

 
As shown, the Prompt Clinic gave it a score of 3 (Solid), because it is very broad and missing many details. That’s still good enough for now.

 
 

Step 4 - Refine the request

 

In the previous step, the agent first suggested a first milestone that it can work togethers, then asked 2 questions, one on the color of bricks, and another one whether to get started on the first milestone.

It is always a good idea to answer the agent’s questions, unless you want to make big changes in the plane.

In this case, suppose we don’t want the agent to start coding yet. Instead, we want it to prepare all the sprites and the backdrop first. We can provide more details like this: make the bricks colorful. Also, don’t work on any code yet. For first milestone, only prepare the sprites and the backdrop.

This is a fairly “strong” prompt that specifies the exact scope of work for the agent to work on. As you will see, the Prompt Clinic rated it as 5 (Exceptional).

 
After some thoughts, the agent decided that it has enough information to get to work! It generated a simple blue background, and 5 colored bricks. During this time, the XO chat window is minimized at the bottom right, so we can observe what it is doing. When it is done, it presents a summary of what it did for us to review, and also suggests what can be done next:

 
The stage looks like this now:

 
 

Step 5 - Prepare more assets

 

In the previous step, the agent did not generate the paddle and the ball, which are also essential to the breakout game. This is because the agent is instructed to only work on small milestones and do not do “too much” in each run. This allows the user to review its work without overwhelming them. In this case, the agent already created a backdrop and 5 brick sprites, so it “feels” this may be a good time to stop.

For this step, we can simply make it finish the artwork: add the paddle and the ball, and remove the dog sprite. Of course, we could just remove the dog sprite ourselves, but this is a good test.

 
It turns out the agent did a pretty good job in following our instruction.

 
 

Step 6 - Improve the assets

 

Before continuing, we should fix another problem: the agent added 5 brick sprites with different colors. However, to be more efficient, we should only have one brick sprite with multiple costumes, so we can easily create clones of this sprite. This is where if you know how to code already, you can point out issues with the agent’s work.

 
As shown, the agent created the single Brick sprite, and then deleted most of the existing bricks. It somehow missed the purple brick (the agent is not perfect), so we have to delete it ourselves to save time.

Now the project has all the sprites we need, and the agent also renamed our project based on our request:

 
 

Step 7 - Add Code Blocks

 

Finally, we are ready to ask the agent to start coding. It is always a good idea to give the agent a small milestone to work on. In this case, let’s make it focus on the bricks:now add code to the Brick sprite so it creates 5 rows of bricks, 10 in each row, using clones.

 
This time the agent added some blocks to the Brick sprite. It will create the bricks at top like this:

 
 

Step 8 - Retry a step

 

Whenever we submit a new request, a snapshot of the entire project is taken, so if we don’t like what the agent did, we can revert the project to its previous state and try again.

In this example, the bricks are all the same color for each row. Suppose we want to make the colors more random, we can send a new message to ask the agent to fix it, or we can trigger a “retry”:

 
As shown, after we click “retry” and confirm, the project is reverted to its state before any code was added to the Brick sprite, and our message is copied into the input box for us to reuse. In this case, we will simply add some addition requirement that the bricks have to be random:

 
Now we get a random brick wall like this:

 
The game is still not done, but we will stop the example here since you have seen how the agent works. Feel free to create this game or any other project you like.

 
 

Conclusion

In summary, the XO agent is not perfect, but it can already help you build your dream project faster and maybe better. The more you use it, the more you will understand its strength and weakness. Give it a try!

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.