How to Prototype Products With Cursor Agents and Grokbots

Leave a Comment / Software Development / By /

The first prototype looked like an admin panel. It worked. Nobody on the team wanted to play it.

That is the actual problem this workflow solves: a tiny team trying to ship a competitive bot-battling game people will click through, not a text-and-numbers UI that exposes Elo, stat lines, and internal jargon. The stack is Cursor agents plus Grokbots. The method is visual context, specialist bots, parallel polish, and a core loop you can play before the graphics are good.

If you run the same sequence, you should be able to mock the product so an agent can see it, stand up a clickable loop in a shared repo, keep bot instructions reusable, and know which decisions still need a human. Draw it, let the agent screenshot it, then iterate in the running prototype — do not start by picking an animation framework.

Key takeaways for Cursor agents and Grokbots

  • Draw mocks in tldraw inside Cursor’s browser so the agent can screenshot them and build from that context, instead of inventing layout from a text prompt.
  • Give players a game, not the guts: hide raw Elo and in-round stats; show tiers, relative strength, and a post-match summary.
  • Every Grokbot gets one job and a high-level description (the team treats that description like a system prompt). If a rule came from one bad chat, it is already overfitted.
  • Use Cursor design mode (shift-click the UI) and multitask mode so polish is a pile of tagged fixes, not a single blocked agent.
  • Keep character art in code for now; use Grok Imagine (then background removal) for skill icons, not as the bot bodies you then cannot animate.
  • Ship the loop first. Animations, medals, 3D, and a full landing page come after something is playable on main.
  • Agents verify better when they can run the product. Comments that explain workarounds are a smell — delete them rather than accumulating them.
  • For anything competitive, assume client-side debug menus and feature-flagged cheats will be abused. Matchmaking and battle resolution need to be server-driven before you put it in the wild.

Who this is for (and who should skip it)

This is for a founder, operator, or product lead who will actually sit in Cursor, push to a shared repo, and read bot descriptions — not for someone who wants a support chatbot bolted onto a helpdesk. The working example is a three-person game studio trying to get a cupcake battler playable in days, with Grokbots on the roster and Cursor agents writing and clicking through the app.

Skip it if you do not have (or will not use) Cursor, a Grokbot-style roster, and a git remote you are willing to treat as the source of truth. The team pushed straight to main until three people were colliding, then switched to pull requests. You need enough technical comfort to run the app locally, hide a debug menu before deploy, and notice when a landing page is still speaking prototyping language.

Give the agent a picture, not a speech

The first job is not “prompt a bot to invent the product.” Lauren blocked time on a whiteboard in tldraw, inside Cursor’s browser, and sketched the screens: game view, new match, captain picker, hired-bot list, team page, import, drag-and-drop order, finding-match, then one bot per round.

What you are trying to accomplish: a shared picture of the loop so an agent has “very useful context” instead of guessing. Prepare a rough mock, not a finished design system. Working title is fine. Captain-has-later-implications can stay undecided.

  1. Open tldraw in Cursor’s browser and sketch the screens in order of play.
  2. Tell the agent to look at the browser. It takes a screenshot and uses that as build context.
  3. Keep a simple account-scoped list of bots you have imported or hired. An “import” control on the picker and a team page are enough for V1.
  4. Optional later: track who minted the bot (original creator vs. the person who uploaded it) as an Easter egg, not as a blocker.

Good looks like a mock the team can point at: big, minimal, bots taking over the screen — not a dense dashboard. Failure looks like the earlier prototype: “some kind of UI” that does not feel like a game. If the generated screens do not match the mock, say so in design mode instead of re-explaining the whole product.

Design the loop so players never see the guts

The product decision underneath the mocks is consistent: players should play, not inspect the simulation. Elo exists; the player sees Diamond, not 1372. Stats exist (they talked about a 150 total cap); the player sees relative strength, not “Rizz was 37 charisma.”

What players see in a match

  • Pick a captain from bots you already have, then assemble the rest of the team (two more bots in their sketch). Captain may matter later; it does not have to yet.
  • Reorder with drag and drop, confirm, then a finding-match state. Ideally matchmaking is fast enough that this screen never appears; if it takes more than a few seconds, add a loading animation rather than a wall of copy.
  • Rounds show one of your bots at a time against one of theirs — not a text soup of both teams and every number.
  • Chunk stats into bands (they sketched 0–20, 20–40, 40–80) and show weak vs. strong, or arrows of power. Hide the numbers in the fight. People who want to dig can get numbers later.
  • Do not preview that the opponent is legendary. Reveal it in the moment so the turn has drama.
  • After the match, a summary of all bots is useful: why you lost, what to tweak next round, and something people might share. That is where stats can reappear.
  • Rank change: show tier plus or minus a number, or an arrow, not the raw Elo. A later idea: medals (bronze / silver / gold / platinum) next to the handle, with the real number on hover.

They also caught a design hole in their own V1: a reroll-team control. If you can see the random bots and spam reroll until you have three legendaries, you will. The fix they liked was pick your captain, receive two hidden bots, and only then decide whether reroll still exists.

Good is a loop you can click without reading. Failure is guaranteed-win math on a stat line, a useless “next round” button, and a match that dumps details on a card when you only wanted the avatar. Auto-advance rounds after a few seconds, then auto-find a new match after about five seconds, beat a click-through slideshow.

Iterate on the running prototype, not on a spec

Once something is on screen, stop describing the game and start marking it up. Cursor design mode lets you shift-click a screen or element and tell the agent what is wrong: three big cards, captain selector first, make the row draggable, remove the reorder button, drop the stat line, pin the header, delete the extra container, keep the number attached when the card rotates.

What to prepare: the prototype running locally, mocks nearby, and a willingness to refresh when the agent’s output has not landed yet. Several people can work if someone is pushing; they started with commit-and-push-to-main (“no time for PRs”) and only switched to pull requests when three people were editing at once. If a cloud agent is behind, tell it to rebase on main.

Good is a captain flow, a match, persistent Elo, and a loop you can play even if you lose. One run showed Diamond at 1240, then 1258 after a win — enough to know accounts and ranking were sticking. Failure is a finding-match state that pops and dies with no animation, CSS that clips on rotate, and copy that still reads like a prototype.

When you are unsure how to do animations, do not pick a library in the abstract. The recommendation in Potato Mode: keep prototyping. Tell the agent to research programmatic animations in JavaScript, build small examples, and look at existing Grokbot motion (2D that still reads as rotation, flips, eyes that follow). Start 2D. Graphics are a layer on top of the logic; you can revamp them after the loop is real. 3D is a later milestone, not the prototype.

Specialist Grokbots, then parallel Cursor agents

The roster is not “one mega-agent.” Dr. Eggbot is the bot they kept recommending for other bots: it writes a description (called a soul / system prompt in the session), sets a voice, and assigns one job so the bot does not try to do everything. Labels (Tater vs. engineer) are treated as cosmetic memory aids, not behavior. Download Dr. Eggbot in the Grokbot app if you want it on your roster; they also use it for a health check on existing prompts.

Cupcake Engine’s job, after a rewrite, was high-level: game-studio context, one job, own engineering outcomes by orchestrating P-Stack, Potato Mode, and cloud agents, then supervise and verify. Match the playbook. When the first description was a pile of incident-specific instructions, they sent it back: too specific, read Potato Mode again, write principles instead of a souvenir of one chat.

Comment Siko exists because agents use comments as a crutch for workarounds instead of fixing the root cause. Over time the app fills with comments and becomes unmaintainable. The bot’s job is to delete them. The name is a riff on a colleague’s “siko mode” skill.

On the Cursor side, multitask mode is the other multiplier. Tag several UI problems, start multitasking, and you get a sub-agent per item. That is the difference between being blocked on one bot and parallelizing “fix this, change this, do that.” You can queue a prompt (they queued tier badges with color for platinum, diamond, and the rest) or interrupt and steer. Computer-use agents that play the game themselves are how they check whether a build actually runs.

Split work the same way you split bots. In the session: one person on auth so they could sign in and fight each other; one on assets, ability icons, and a mini tutorial; one on the main game loop (rounds should not require a click each time). Playtesting is not optional — the mechanics are “rock paper scissors with some numbers,” so player feel and animation carry the product.

Use case Bot / tool Input needed Output Owner
Engineering the prototype Cupcake Engine, Cursor agents, P-Stack, Potato Mode Repo, mocks, playbook Running loop, commits, supervision Engineering lead
Rewrite and health-check bots Dr. Eggbot Existing descriptions, Potato Mode One-job prompts, less overfit copy Whoever owns the roster
Stop workaround comments Comment Siko Codebase comments Comments removed at the root-cause layer Engineering
Skill / ability icons Grok Imagine, Fal Refnet V2, image-gen bot Mechanics, existing design language On-brand icons with transparent backgrounds Design / assets
UI polish in parallel Cursor design mode + multitask Tagged elements on the live UI Many small visual fixes at once Whoever is in the prototype
Landing / first impression Cursor, Grok 46 low effort fast Real marketplace bots, not fictional ones Hero + Play, not a spec dump Whoever owns the lander
Ship-ready access Human + agents Accounts, anti-cheat constraints Auth; later, server-driven battles One teammate
GTM / monetization sketch Bots as needed Stadium / banner concept Non-intrusive ads, possible bid + moderation One teammate

Prompts, bot instructions, and workflows

These are cleaned from what they actually told the agents. Reconstructions are labeled. Do not turn them into a different method.

Point the agent at the whiteboard

Look at my browser. I drew some mocks in tldraw. Take a screenshot and use that as context to build the screens.

Design-mode feedback on a live screen

This doesn't match my mocks.

Three big cards. First card is the captain selector. The other two cards are the rest of the team.

This row should be draggable to reorder. Remove the reorder button.

Don't show this card. Just the bot avatar. Remove the stat line.

When the card rotates, this number stays attached to the card and rotates with it.

Delete this container so the rest of the UI can overlay at full height.

When you're done, commit and push to main.

Reconstructed from the speaker’s description.

When you do not know the animation approach

Help me research game animation frameworks.

Look up how to do programmatic animations with JavaScript.
Prototype a few small examples. Do not commit us to a library yet.
Start 2D. Prefer code-driven motion we can iterate, similar in spirit to Grokbot avatars that rotate and whose eyes follow, still in 2D.

Reconstructed from the speaker’s description.

Chain Imagine for skill icons, not bot bodies

Have Cupcake Engine talk to the image-gen bot.
Explain the repo we are working in and the game mechanics.
Build cool skill icons using Imagine. Remove the background.
These need to be on brand. Use the existing design language.

Reconstructed from the speaker’s description. The image pipeline they already liked: Grok Imagine for the art, then a Fal Refnet V2 background-removal model so you get a transparent PNG. They explicitly decided not to make the fighters themselves PNGs, because a JavaScript animation path is painful if the characters are flattened images. Sprite sheets (idle, angry, battle, happy) were the fallback if they left code-drawn bots later. Imagine can still do hero assets.

Fix an overfitted bot description

The description you came up with for Cupcake Engine is way too specific.
Read Potato Mode again and come up with principles Cupcake Engine should follow
instead of these overly specific issues.

Landing page that does not leak the prototype

Stop using prototyping language on the lander.
Look at the bot marketplace and use real bots, not fictional ones.
Do not put internal build details on the page.
Keep the hero (cards / bot stack) and a big Play button that starts login.
Cut the rest of the fluff.

Reconstructed from the speaker’s description. Matt’s preferred design-mode combo in the session was Grok 46, low effort, fast — so you can rip through spacing, type, and nonsense copy quickly.

Cupcake Engine, after the rewrite (direction, not a full dump)

High-level context on our game studio.
One job: own engineering outcomes by orchestrating work through P-Stack, Potato Mode, and cloud agents, then supervising and verifying.
Match the playbook and follow it.

They still called some of that “AI slop” and planned to clean it. The point is the shape: durable principles, one job, not a transcript of last Tuesday’s bug.

What to check before you call it shippable

Nobody in the session quoted hours saved, cost per match, or lead volume. The checkpoints they actually used:

  • Can you click captain → order → match → rounds without thinking? If yes, the loop is real even if you keep losing.
  • Does Elo persist across refresh (they saw Diamond 1240, then 1258 after a win)?
  • Does the UI still show stat lines, raw Elo, debug cheats, or prototyping copy? Then it is not ready for players.
  • Can three of you sign in and fight each other? Auth is the gate to playtesting, and playtesting is the gate to “player feel.”
  • V1 leaderboard is just highest Elo. Replays, medals, and fancier tiers wait. Bragging rights are the point (“who’s the best cupcake battler”).

Business-side, they only sketched GTM: a stadium instead of bots in outer space, non-intrusive banners, maybe an ad marketplace with bidding and human moderation of who gets to show up. That was a bot to kick off later, not a metric they had.

Pitfalls and where a human stays in the loop

  • Overfitted skills. When a rule is born from one failure in one session, agents stuff the entire incident into the skill. Reuse dies. You get a soup of stale examples. A human has to open the description, notice it, and send the bot back to principles (Potato Mode, one job, durable language).
  • Comment rot. Agents explain the workaround in a comment instead of fixing the cause. Comment Siko is the guardrail; a human still has to care that the codebase stays maintainable.
  • Text and numbers as the default UI. “The enemy of the game design here is too much text and numbers.” If the fight is a stat dump, you shipped the simulation, not the game.
  • Reroll and client cheats. Visible randoms plus reroll equals legendary farming. A debug menu that can boost charisma to 43 is fun internally and fatal in production. Feature flags are not enough: the code still ships, and someone can tweak values in the console. Hide the debug menu. Move matchmaking and resolution to the server before competitive play.
  • Landing pages that confess. Models invent fictional bots, paste internal specifics, and write how-it-works copy nobody asked for. A human has to answer “why is this fun?” and cut to hero plus Play — or skip the lander and drop into sign-in, which they also debated as lower friction.
  • PNG trap. Cute Imagine characters with the background removed still fight you if you then need code-driven motion. Keep fighters in code; Imagine the icons.
  • One-agent bottleneck. Forgetting multitask means you wait on a single bot for every CSS nick. Parallelize polish; serialize the core loop until main is stable enough to branch.
  • Animation without design chops. They were honest: good win/lose motion may need a person, references, or many small prototypes, not one “write us a framework” prompt.
You don’t have to see the guts of how the game works. You just want to play the game.
I find that agents tend to put all the details in that rule or skill and then it makes the skill less reusable.
Agents do a lot better when they can verify their output.

A 7-day plan to run the same method

They were on a three-day build and said they were about halfway. This stretches that same sequence so you can repeat it without inventing extra process.

Day 1

Whiteboard the loop in tldraw inside Cursor. Captain, team, match, one-bot rounds, summary. Decide what is hidden in-fight (numbers, opponent rarity, raw Elo) versus what appears after. Point an agent at the browser. Stand up the ugliest clickable path you can. Do not name the product yet if you do not have to.

Days 2–3

Get the prototype on a shared main. Design-mode the screens until they match the mock: drag-and-drop order, no extra reorder chrome, avatars not stat cards, pinned header. Let agents run the loop themselves. If matchmaking is instant, keep the finding-match state anyway until you add motion — then ship and iterate. Start a specialist engineering bot with one job and a short playbook, not a memoir of today’s bugs.

Days 4–5

Rewrite any overfitted descriptions (Dr. Eggbot + Potato Mode). Generate ability icons with Imagine and background removal; leave bodies in code. Turn on multitask for polish. Implement auth so real accounts can play. Kill or hide the debug menu. Add a Play-first hero if you need a door; cut marketplace fiction and prototyping language. Spawn Comment Siko on the repo before comments become policy.

Days 6–7

Playtest with the actual team signed in. Auto-advance rounds; only then invest in win/lose animation research via small JS prototypes, still 2D. Leaderboard V1 = Elo sort. Put rank as a tier (tooltip for the number if you must). List what must be server-driven before strangers can cheat. If you care about GTM, sketch stadium ads as a separate bot thread — non-intrusive, moderated — and do not block the loop on it.

The outcome is not a perfect game. It is a loop on main that a few people can play, with bots that stay specialist, a UI that does not leak the simulation, and a list of human jobs (feel, anti-cheat, prompt hygiene) you will not automate yet. Watch the video for the walkthrough of tldraw-in-Cursor, design mode, and multitask — then start with one specialist bot and one mocked loop, not a roster of twelve.

FAQ

Do I need Grokbots if I already use Cursor agents?

The team used both on purpose. Cursor agents build, click, screenshot, multitask, and push the app. Grokbots like Dr. Eggbot, Cupcake Engine, and Comment Siko hold jobs, voices, and playbooks that persist across the work. If you only have Cursor, you can still steal the visual-context and design-mode loop; you will have to keep the “one job, high-level description” discipline yourself.

tldraw vs. prompting the agent to invent mocks — which first?

They could have prompted a bot for the whiteboard and chose not to. Drawing it themselves, in the browser the agent can see, was for thinking and for context. Use tldraw first when you care about layout and feel; let the agent riff after it has a screenshot, not before.

Grok Imagine vs. code-drawn bots — which should I use?

Keep the characters in code for V1 so states stay flexible. Use Grok Imagine for skill icons (and maybe hero shots), then Fal Refnet V2-style background removal for transparent assets. Sprite sheets are the compromise if you insist on image-based 2D frames. 3D is a later milestone.

Do I need a landing page or should players drop straight into sign-in?

They disagreed in the room. One view: the sign-in screen is enough and a lander adds friction. The other: an app needs a home, and a strong hero plus Play is that home. What they agreed to cut was fluff, fictional bots, and prototyping language. If you keep a lander, keep the card stack and a Play button that starts login.

Potato Mode vs. a long bot description — what is the difference?

Potato Mode here means stay high-level, keep prototyping, and research with small examples when you are unsure. A long description that encodes one incident is the failure mode. If Dr. Eggbot (or any agent) writes a novel, send it back to principles and one job.

Does a bot’s label change how it behaves?

In the session they believed the label was cosmetic — a reminder when your bots are named Tater, Mash, and Hash Brown. Behavior lives in the description. Someone else on the team could correct that later; do not build logic on the label until you verify it.

When do we stop pushing to main?

They pushed to main while moving fast, then switched to pull requests once three people were collaborating and needed bots to reconcile diffs. Use main until collision cost is real; do not wait for a perfect branching strategy to get a playable loop.

What has to stay human in a competitive product?

Playtesting, reading bot descriptions, deciding what players are allowed to see, animation taste, and anything that prevents cheating (hiding debug tools, server-driven battles, moderating who can buy ad space). Agents can implement and even run the loop to verify. They should not be the last word on feel or integrity.