How to use Cursor to build a courtroom card game
Cursor custom modes built a courtroom card game. Scoped review caught turn bugs, while the maker corrected tool permissions and repaired confusing UI edits.
Suggested prompt
Suggested prompt written by Agents In Use, not the source author. Replace bracketed inputs and review tool permissions first.
Use the supplied Godot card-game requirements to plan and implement one turn-system change at a time. Let a reviewer inspect the actual diff with terminal access, test card-effect preconditions and preserve UI nodes. Ask for visual references rather than guessing layouts, and leave final play checks to me.
Reach people exploring AI agents
See placements →What happened
A functional hackathon courtroom game was built with basic visuals. Reviews caught logic defects, while the author manually fixed UI failures and corrected reviewer permissions.
Reported by Victor Da Luz — Personal blogHow the agent did it
- Da Luz answered requirements questions and let specialized Cursor modes produce design and implementation documents.
- Planner, developer and reviewer modes iterated changes, with terminal access added for git diff.
- The human tested turns and repaired UI mistakes that prompted development had not resolved.
Where a person stepped in
Da Luz answered requirements questions, fixed reviewer permissions, tested the game and manually repaired misunderstood UI changes.
Victor Da Luz built a two-player courtroom card game for a hackathon using Cursor custom modes while learning Godot. He divided the work among a requirements interviewer, architect, planner, developer, reviewer and technical writer, giving each mode different tools and output files.
The initial roles produced requirements, a system design and an implementation plan. The ongoing loop became simpler: the planner proposed work, the developer implemented it and the reviewer inspected changes. When the reviewer kept failing to run git diff, Da Luz discovered that he had omitted terminal access and corrected its permissions. He also narrowed review scope to changes rather than entire files.
The result was a functional game with basic visuals and documentation, but development required repeated human intervention. One card-effect change broke the turn system; review caught it only after failed test runs. Another refactor removed buttons. UI requests were especially unreliable because the developer had no visual design to follow.
Da Luz manually repaired misunderstood layouts and tested the game. The useful account is a concrete role-and-tool workflow plus its failure points: a review agent could catch missing preconditions and logic bugs, while neither specialized roles nor a large plan eliminated the need to play and inspect the interface.
Prompt
Suggested prompt (written by Agents In Use, not the author's)
Source: Personal blog · Victor Da Luz
Frequently asked questions
Why did review initially fail?
The reviewer lacked terminal permission needed to run git diff.
What concrete bug did review catch?
A card-effect change had broken the turn system.
Did the agent handle the whole interface?
No. Da Luz manually repaired misunderstood layouts and missing buttons.
More details
About this account
Da Luz answered requirements questions and let specialized Cursor modes produce design and implementation documents. Planner, developer and reviewer modes iterated changes, with terminal access added for git diff.
Original hackathon account opened. Functional game screenshots and concrete failures are reported; visuals were basic and developer edits sometimes broke turns or removed buttons. Suggested prompt written by Agents In Use; no original task prompt was published in the verified account.
Credit: Victor Da Luz — Personal blog
Source published 28 Jun 2025
Source checked 14 Oct 2026
Tools and topics
Cursor · Godot · Git
Card game · Agent review
Editorial completeness: 100/100. Measures documented fields, not agent performance or verified outcomes.