How to use Gemini to build and check Cloud Crush
Gemini CLI built Cloud Crush in Go and used a browser subagent to check its canvas. Plan review and human playtesting remained distinct from screen checks.
Original prompt
Shared by the source author. See source notes for context.
Build a Match-3 game called 'Cloud Crush' in Go using Ebitengine v2.
Reach people exploring AI agents
See placements →Evidence at a glance
Sourced account- Source author
- Daniela Petruzalek
- Original account
- Read the source ↗
- Published
- Source link checked
- Reported result
- Cloud Crush ran with compiled native and web targets and browser-based visual checks. Human game-feel review and a report-only security subagent remained separate checkpoints.
- Human involvement
- Petruzalek chose the engine and visual assets, reviewed the plan and retained human playtesting for game feel.
A linked account supports attribution. It does not mean we independently reproduced its result.
Report an issue with this case
Open correction emailOpens your email app with the case link included. Nothing is sent automatically.
How the agent did it
- Petruzalek supplied board, asset and UI requirements and reviewed Gemini's plan.
- Gemini implemented and compiled the game, including its WebAssembly target.
- A visual browser subagent played the canvas game and captured screens while human playtesting judged feel.
Daniela Petruzalek used Gemini CLI to build Cloud Crush, a match-three game in Go with Ebitengine. She supplied a background, product-logo sprites and specific board and interface requirements, then used plan mode to resolve choices before implementation.
The agent wrote the game and compiled native and WebAssembly targets. The web version created a testing problem: the entire game was drawn on a canvas, so the browser's accessibility tree exposed little useful structure. Petruzalek enabled a browser subagent with a visual model to inspect screenshots and choose click coordinates instead.
That agent could visit the live application, play a round and capture working screens. Human playtesting still judged game feel. Petruzalek also pointed a separate read-only security subagent at the codebase to examine credentials, file handling and deployment risks, without allowing it to silently edit implementation.
The source includes a running-game screenshot and the actual design prompt, making this a worked project rather than an abstract feature list. Its transferable distinction is between algorithm checks, visual canvas interaction and human experience review. The article does not claim that screenshots prove every possible state correct or that the baseline security review replaces professional assessment.
Prompt
Original prompt
Source: Personal blog · Daniela Petruzalek
Frequently asked questions
Why use a visual browser model?
The canvas did not expose its game controls through a useful accessibility tree.
What did the browser agent do?
It visited the live game, played a round and captured working screens.
Could the security subagent edit code?
No. Its published tool set was read-only and its role was to report.
More details
About this account
Petruzalek supplied board, asset and UI requirements and reviewed Gemini's plan. Gemini implemented and compiled the game, including its WebAssembly target.
Firsthand worked tutorial opened; author is a Google developer relations engineer. Source documents its original Gemini CLI workflow and later notes a tool transition. Security subagent was report-only and no specific vulnerability finding is claimed. Original prompt excerpt.
Credit: Daniela Petruzalek — Personal blog
Source published
Added to Agents In Use
Source checked
Tools and topics
Gemini CLI · Go · Ebitengine · WebAssembly · Cloud Run
Match-three game · Canvas verification
Editorial completeness: 100/100. Measures documented fields, not agent performance or verified outcomes.