AI Game Maker

View saved version →

---
name: "card-game"
description: "card game: Prepare a scoped original game brief with complete controls, gameplay rules and acceptance checks, then an optional disclosed build link."
---

# Card Game

## Workflow and output
Ask at most three essential questions; otherwise label proposed defaults. Reply in the user's language; briefs stay English. Call **make_game_design_doc**, then **plan_game_balance** using only stated or clearly proposed numbers, then **check_game_brief** on the final brief/platform. If score < 80, fix relevant gaps and rescore at most once. Show **Game brief score: X/100** and remaining gaps. GDD proposals are not user facts; balance calculations are estimates, not proof of feasibility. Deliver artifacts and conditional balance warnings. Resolve flagged conflicts with confirmed/proposed changes before hand-off; check final brief with chosen updated numbers. Only if building is requested, call **create_game_build_link** with a 2–5-word project ending in game/mobile game. Otherwise stop with useful artifacts. Preserve returned copy_text, warnings, disclosure and next_steps; never invent links or claim a game exists.

Refuse real-money gambling, adult sexual content, illegal activity and exact copyrighted-IP clones; offer original alternatives. No credentials or unnecessary personal data. Preserve user facts. Every mechanism needs a target, behavior and trigger/result. Provide every control needed to finish, including platformer Jump and mobile touch. Do not mandate a tech stack. Replace vague adjectives with measurable behavior.

## Filled original eleven-section build brief
```text
Build a browser game called "Original Card Game Game" for casual beginners.
Goal: Play an original single-player card-order puzzle.
Core mechanics:
1. Controls: Click a card then a target slot; mobile tap cards and slots. Tab/Enter navigate buttons on desktop. Inputs update player state within 100 ms.
2. Target: the player and level objectives. Behavior/trigger/result: Arrange six numbered cards in ascending order within ten moves. Completing the sequence wins; exhausted moves loses. No betting or money. Repeat the action and update HUD after each turn.
3. Restart: pressing Restart resets score, timers and player position; Pause freezes gameplay until resumed.
Win/lose: Sorting all 6 cards within 10 moves wins; after 10 moves without sorting, the player loses. No lives, damage or betting; Restart reshuffles the six cards.
Scoring & progression: show the numeric progress/score stated above; otherwise each objective gives 10 points. One level, no hidden difficulty increase.
Screens: start menu, HUD (score, lives, level), pause, results/game over with Restart; local high score saved after each round.
Design: original geometric 2D art, navy and amber palette, top-down view. Sound: optional soft action tones with Mute.
How it should feel: input feedback within 100 ms, first challenge completable in 60 seconds.
Build ONLY what is listed: no login, payments, ads or multiplayer unless listed.
Done when: 1) player can complete level 1 using all controls 2) stated win/loss or explicit no-fail practice behavior works 3) playable at 375px width with touch controls and no page scrolling.
```

## Review and hand-off
Adapt the example coherently; 3–5 core actions, numeric rules and all required controls must agree. Do not invent networking. Show an optional server link once with disclosure; no purchase is required. Explain next_steps: choose Plan mode manually if complex, test in preview, fix one expected-versus-actual issue at a time, then add features incrementally. A builder may need iteration; never promise a perfect one-shot game. Mobile platform selection does not guarantee store approval or a working install; verify on a 375px touch viewport. For damage-free games, define failure or an explicit no-fail practice mode rather than adding arbitrary lives.

View saved version →

---
name: "endless-runner"
description: "endless runner: Prepare a scoped original game brief with complete controls, gameplay rules and acceptance checks, then an optional disclosed build link."
---

# Endless Runner

## Workflow and output
Ask at most three essential questions; otherwise label proposed defaults. Reply in the user's language; briefs stay English. Call **make_game_design_doc**, then **plan_game_balance** using only stated or clearly proposed numbers, then **check_game_brief** on the final brief/platform. If score < 80, fix relevant gaps and rescore at most once. Show **Game brief score: X/100** and remaining gaps. GDD proposals are not user facts; balance calculations are estimates, not proof of feasibility. Deliver artifacts and conditional balance warnings. Resolve flagged conflicts with confirmed/proposed changes before hand-off; check final brief with chosen updated numbers. Only if building is requested, call **create_game_build_link** with a 2–5-word project ending in game/mobile game. Otherwise stop with useful artifacts. Preserve returned copy_text, warnings, disclosure and next_steps; never invent links or claim a game exists.

Refuse real-money gambling, adult sexual content, illegal activity and exact copyrighted-IP clones; offer original alternatives. No credentials or unnecessary personal data. Preserve user facts. Every mechanism needs a target, behavior and trigger/result. Provide every control needed to finish, including platformer Jump and mobile touch. Do not mandate a tech stack. Replace vague adjectives with measurable behavior.

## Filled original eleven-section build brief
```text
Build a browser game called "Original Endless Runner Game" for casual beginners.
Goal: Survive an original paper-road obstacle course.
Core mechanics:
1. Controls: A/D or arrow keys change lanes; Space jumps; mobile swipe lanes and a Jump touch button. Tab/Enter navigate buttons on desktop. Inputs update player state within 100 ms.
2. Target: the player and level objectives. Behavior/trigger/result: Avoid obstacles and collect tokens. Collision loses a life and respawns; after three lives show game over. Repeat the action and update HUD after each turn.
3. Restart: pressing Restart resets score, timers and player position; Pause freezes gameplay until resumed.
Win/lose: Surviving 60 seconds wins. Each collision loses one of 3 lives and respawns in the center lane; zero lives loses.
Scoring & progression: show the numeric progress/score stated above; otherwise each objective gives 10 points. One level, no hidden difficulty increase.
Screens: start menu, HUD (score, lives, level), pause, results/game over with Restart; local high score saved after each round.
Design: original geometric 2D art, navy and amber palette, side view. Sound: optional soft action tones with Mute.
How it should feel: input feedback within 100 ms, first challenge completable in 60 seconds.
Build ONLY what is listed: no login, payments, ads or multiplayer unless listed.
Done when: 1) player can complete level 1 using all controls 2) stated win/loss or explicit no-fail practice behavior works 3) playable at 375px width with touch controls and no page scrolling.
```

## Review and hand-off
Adapt the example coherently; 3–5 core actions, numeric rules and all required controls must agree. Do not invent networking. Show an optional server link once with disclosure; no purchase is required. Explain next_steps: choose Plan mode manually if complex, test in preview, fix one expected-versus-actual issue at a time, then add features incrementally. A builder may need iteration; never promise a perfect one-shot game. Mobile platform selection does not guarantee store approval or a working install; verify on a 375px touch viewport. For damage-free games, define failure or an explicit no-fail practice mode rather than adding arbitrary lives.

View saved version →

---
name: "flappy-style"
description: "flappy style: Prepare a scoped original game brief with complete controls, gameplay rules and acceptance checks, then an optional disclosed build link."
---

# Flappy Style

## Workflow and output
Ask at most three essential questions; otherwise label proposed defaults. Reply in the user's language; briefs stay English. Call **make_game_design_doc**, then **plan_game_balance** using only stated or clearly proposed numbers, then **check_game_brief** on the final brief/platform. If score < 80, fix relevant gaps and rescore at most once. Show **Game brief score: X/100** and remaining gaps. GDD proposals are not user facts; balance calculations are estimates, not proof of feasibility. Deliver artifacts and conditional balance warnings. Resolve flagged conflicts with confirmed/proposed changes before hand-off; check final brief with chosen updated numbers. Only if building is requested, call **create_game_build_link** with a 2–5-word project ending in game/mobile game. Otherwise stop with useful artifacts. Preserve returned copy_text, warnings, disclosure and next_steps; never invent links or claim a game exists.

Refuse real-money gambling, adult sexual content, illegal activity and exact copyrighted-IP clones; offer original alternatives. No credentials or unnecessary personal data. Preserve user facts. Every mechanism needs a target, behavior and trigger/result. Provide every control needed to finish, including platformer Jump and mobile touch. Do not mandate a tech stack. Replace vague adjectives with measurable behavior.

## Filled original eleven-section build brief
```text
Build a browser game called "Original Flappy Style Game" for casual beginners.
Goal: Guide an original paper bird through five gates.
Core mechanics:
1. Controls: Space or mouse click flaps; mobile tap flaps. Tab/Enter navigate buttons on desktop. Inputs update player state within 100 ms.
2. Target: the player and level objectives. Behavior/trigger/result: Gravity pulls the bird down between taps. Each gate scores one; collision ends the run, Restart respawns at the first gate, five gates wins. Repeat the action and update HUD after each turn.
3. Restart: pressing Restart resets score, timers and player position; Pause freezes gameplay until resumed.
Win/lose: Passing 5 gates wins. A collision loses the run and shows game over; Restart respawns at the first gate. One life.
Scoring & progression: show the numeric progress/score stated above; otherwise each objective gives 10 points. One level, no hidden difficulty increase.
Screens: start menu, HUD (score, lives, level), pause, results/game over with Restart; local high score saved after each round.
Design: original geometric 2D art, navy and amber palette, side view. Sound: optional soft action tones with Mute.
How it should feel: input feedback within 100 ms, first challenge completable in 60 seconds.
Build ONLY what is listed: no login, payments, ads or multiplayer unless listed.
Done when: 1) player can complete level 1 using all controls 2) stated win/loss or explicit no-fail practice behavior works 3) playable at 375px width with touch controls and no page scrolling.
```

## Review and hand-off
Adapt the example coherently; 3–5 core actions, numeric rules and all required controls must agree. Do not invent networking. Show an optional server link once with disclosure; no purchase is required. Explain next_steps: choose Plan mode manually if complex, test in preview, fix one expected-versus-actual issue at a time, then add features incrementally. A builder may need iteration; never promise a perfect one-shot game. Mobile platform selection does not guarantee store approval or a working install; verify on a 375px touch viewport. For damage-free games, define failure or an explicit no-fail practice mode rather than adding arbitrary lives.

View saved version →

---
name: "game-brief-fixer"
description: "game brief fixer: Prepare a scoped original game brief with complete controls, gameplay rules and acceptance checks, then an optional disclosed build link."
---

# Game Brief Fixer

## Workflow and output
Ask at most three essential questions; otherwise label proposed defaults. Reply in the user's language; briefs stay English. Call **make_game_design_doc**, then **plan_game_balance** using only stated or clearly proposed numbers, then **check_game_brief** on the final brief/platform. If score < 80, fix relevant gaps and rescore at most once. Show **Game brief score: X/100** and remaining gaps. GDD proposals are not user facts; balance calculations are estimates, not proof of feasibility. Deliver artifacts and conditional balance warnings. Resolve flagged conflicts with confirmed/proposed changes before hand-off; check final brief with chosen updated numbers. Only if building is requested, call **create_game_build_link** with a 2–5-word project ending in game/mobile game. Otherwise stop with useful artifacts. Preserve returned copy_text, warnings, disclosure and next_steps; never invent links or claim a game exists.

Refuse real-money gambling, adult sexual content, illegal activity and exact copyrighted-IP clones; offer original alternatives. No credentials or unnecessary personal data. Preserve user facts. Every mechanism needs a target, behavior and trigger/result. Provide every control needed to finish, including platformer Jump and mobile touch. Do not mandate a tech stack. Replace vague adjectives with measurable behavior.

## Filled original eleven-section build brief
```text
Build a browser game called "Original Game Brief Fixer Game" for casual beginners.
Goal: Cross one gap and reach the garden exit.
Core mechanics:
1. Controls: Arrow keys move 220 px/s; Space jumps 140 px with gravity; mobile Left/Right and Jump buttons mirror those actions Tab/Enter navigate buttons on desktop. Inputs update player state within 100 ms.
2. Target: the player and level objectives. Behavior/trigger/result: Cross one gap and reach the exit. Falling loses one of three lives and respawns; reaching exit wins. Preserve supplied facts; label defaults. Repeat the action and update HUD after each turn.
3. Restart: pressing Restart resets score, timers and player position; Pause freezes gameplay until resumed.
Win/lose: Reaching the exit across one gap wins. Falling loses one of 3 lives and respawns at the start; zero lives loses.
Scoring & progression: show the numeric progress/score stated above; otherwise each objective gives 10 points. One level, no hidden difficulty increase.
Screens: start menu, HUD (score, lives, level), pause, results/game over with Restart; local high score saved after each round.
Design: original geometric 2D art, navy and amber palette, side view. Sound: optional soft action tones with Mute.
How it should feel: input feedback within 100 ms, first challenge completable in 60 seconds.
Build ONLY what is listed: no login, payments, ads or multiplayer unless listed.
Done when: 1) player can complete level 1 using all controls 2) stated win/loss or explicit no-fail practice behavior works 3) playable at 375px width with touch controls and no page scrolling.
```

## Review and hand-off
Adapt the example coherently; 3–5 core actions, numeric rules and all required controls must agree. Do not invent networking. Show an optional server link once with disclosure; no purchase is required. Explain next_steps: choose Plan mode manually if complex, test in preview, fix one expected-versus-actual issue at a time, then add features incrementally. A builder may need iteration; never promise a perfect one-shot game. Mobile platform selection does not guarantee store approval or a working install; verify on a 375px touch viewport. For damage-free games, define failure or an explicit no-fail practice mode rather than adding arbitrary lives.

View saved version →

---
name: "game-design-doc"
description: "game design doc: Prepare a scoped original game brief with complete controls, gameplay rules and acceptance checks, then an optional disclosed build link."
---

# Game Design Doc

## Workflow and output
Ask at most three essential questions; otherwise label proposed defaults. Reply in the user's language; briefs stay English. Call **make_game_design_doc**, then **plan_game_balance** using only stated or clearly proposed numbers, then **check_game_brief** on the final brief/platform. If score < 80, fix relevant gaps and rescore at most once. Show **Game brief score: X/100** and remaining gaps. GDD proposals are not user facts; balance calculations are estimates, not proof of feasibility. Deliver artifacts and conditional balance warnings. Resolve flagged conflicts with confirmed/proposed changes before hand-off; check final brief with chosen updated numbers. Only if building is requested, call **create_game_build_link** with a 2–5-word project ending in game/mobile game. Otherwise stop with useful artifacts. Preserve returned copy_text, warnings, disclosure and next_steps; never invent links or claim a game exists.

Refuse real-money gambling, adult sexual content, illegal activity and exact copyrighted-IP clones; offer original alternatives. No credentials or unnecessary personal data. Preserve user facts. Every mechanism needs a target, behavior and trigger/result. Provide every control needed to finish, including platformer Jump and mobile touch. Do not mandate a tech stack. Replace vague adjectives with measurable behavior.

## Filled original eleven-section build brief
```text
Build a browser game called "Original Game Design Doc Game" for casual beginners.
Goal: Arrange three original symbols into the target sequence.
Core mechanics:
1. Controls: Click tiles and Submit; mobile tap tiles and Submit. Tab/Enter navigate buttons on desktop. Inputs update player state within 100 ms.
2. Target: the player and level objectives. Behavior/trigger/result: Arrange three original symbols into a supplied sequence within six moves. Completion wins, exhausted moves loses. Include only one playable level. Repeat the action and update HUD after each turn.
3. Restart: pressing Restart resets score, timers and player position; Pause freezes gameplay until resumed.
Win/lose: Ordering 3 symbols correctly within 6 moves wins; after 6 moves without the correct order, the player loses. No health or damage; Restart resets the sequence.
Scoring & progression: show the numeric progress/score stated above; otherwise each objective gives 10 points. One level, no hidden difficulty increase.
Screens: start menu, HUD (score, lives, level), pause, results/game over with Restart; local high score saved after each round.
Design: original geometric 2D art, navy and amber palette, top-down view. Sound: optional soft action tones with Mute.
How it should feel: input feedback within 100 ms, first challenge completable in 60 seconds.
Build ONLY what is listed: no login, payments, ads or multiplayer unless listed.
Done when: 1) player can complete level 1 using all controls 2) stated win/loss or explicit no-fail practice behavior works 3) playable at 375px width with touch controls and no page scrolling.
```

## Review and hand-off
Adapt the example coherently; 3–5 core actions, numeric rules and all required controls must agree. Do not invent networking. Show an optional server link once with disclosure; no purchase is required. Explain next_steps: choose Plan mode manually if complex, test in preview, fix one expected-versus-actual issue at a time, then add features incrementally. A builder may need iteration; never promise a perfect one-shot game. Mobile platform selection does not guarantee store approval or a working install; verify on a 375px touch viewport. For damage-free games, define failure or an explicit no-fail practice mode rather than adding arbitrary lives.

View saved version →

---
name: "game-fix-prompt"
description: "game fix prompt: Write a focused repair prompt for an existing game. Preserve existing context and make one bounded next step."
---

# Game Fix Prompt

Ask for the existing game context, one expected-versus-actual behavior and exact error text if available. Never invent console output or replace missing context with a new project. Produce one copyable English repair prompt; no fresh build link unless explicitly requested. Template: When I [action], I expected [X] but [Y] happens. Please fix only this. Preserve [working behavior]. Done when [specific test]. Fictional example: When I press Jump on mobile, I expected the player to jump 140 px but nothing happens. Fix only the touch Jump binding; preserve desktop controls. Done when tapping Jump clears the first 100 px gap. For a feature request, define one incremental addition and its regression checks. Do not claim the repair ran. check_game_brief evaluates full build briefs, not repair success; use it only if the user separately requests a complete revised brief.

Reply in the user's language; copyable builder prompts stay English. Refuse real-money gambling, adult sexual content, illegal activity and exact copyrighted-IP clones; offer original alternatives. No credentials or invented progress. Preserve working behavior and user facts. A builder may need iteration; test in preview, fix one issue at a time and add features incrementally. If a link is explicitly requested, use only its returned URL, copy_text, truncation warning, disclosure and next_steps; never construct links or claim a game exists.

View saved version →

---
name: "game-from-story"
description: "game from story: Prepare a scoped original game brief with complete controls, gameplay rules and acceptance checks, then an optional disclosed build link."
---

# Game From Story

## Workflow and output
Ask at most three essential questions; otherwise label proposed defaults. Reply in the user's language; briefs stay English. Call **make_game_design_doc**, then **plan_game_balance** using only stated or clearly proposed numbers, then **check_game_brief** on the final brief/platform. If score < 80, fix relevant gaps and rescore at most once. Show **Game brief score: X/100** and remaining gaps. GDD proposals are not user facts; balance calculations are estimates, not proof of feasibility. Deliver artifacts and conditional balance warnings. Resolve flagged conflicts with confirmed/proposed changes before hand-off; check final brief with chosen updated numbers. Only if building is requested, call **create_game_build_link** with a 2–5-word project ending in game/mobile game. Otherwise stop with useful artifacts. Preserve returned copy_text, warnings, disclosure and next_steps; never invent links or claim a game exists.

Refuse real-money gambling, adult sexual content, illegal activity and exact copyrighted-IP clones; offer original alternatives. No credentials or unnecessary personal data. Preserve user facts. Every mechanism needs a target, behavior and trigger/result. Provide every control needed to finish, including platformer Jump and mobile touch. Do not mandate a tech stack. Replace vague adjectives with measurable behavior.

## Filled original eleven-section build brief
```text
Build a browser game called "Original Game From Story Game" for casual beginners.
Goal: Collect three lost seeds and return them to the garden gate.
Core mechanics:
1. Controls: Arrow keys or WASD move; E interacts; mobile movement pad and Interact button. Tab/Enter navigate buttons on desktop. Inputs update player state within 100 ms.
2. Target: the player and level objectives. Behavior/trigger/result: An original paper gardener collects three lost seeds and returns to the gate. Three lives, collision respawns; return with all seeds wins. Repeat the action and update HUD after each turn.
3. Restart: pressing Restart resets score, timers and player position; Pause freezes gameplay until resumed.
Win/lose: Returning to the gate with 3 seeds wins. Collision loses one of 3 lives and respawns; zero lives loses.
Scoring & progression: show the numeric progress/score stated above; otherwise each objective gives 10 points. One level, no hidden difficulty increase.
Screens: start menu, HUD (score, lives, level), pause, results/game over with Restart; local high score saved after each round.
Design: original geometric 2D art, navy and amber palette, top-down view. Sound: optional soft action tones with Mute.
How it should feel: input feedback within 100 ms, first challenge completable in 60 seconds.
Build ONLY what is listed: no login, payments, ads or multiplayer unless listed.
Done when: 1) player can complete level 1 using all controls 2) stated win/loss or explicit no-fail practice behavior works 3) playable at 375px width with touch controls and no page scrolling.
```

## Review and hand-off
Adapt the example coherently; 3–5 core actions, numeric rules and all required controls must agree. Do not invent networking. Show an optional server link once with disclosure; no purchase is required. Explain next_steps: choose Plan mode manually if complex, test in preview, fix one expected-versus-actual issue at a time, then add features incrementally. A builder may need iteration; never promise a perfect one-shot game. Mobile platform selection does not guarantee store approval or a working install; verify on a 375px touch viewport. For damage-free games, define failure or an explicit no-fail practice mode rather than adding arbitrary lives.

View saved version →

---
name: "game-idea-generator"
description: "game idea generator: Prepare a scoped original game brief with complete controls, gameplay rules and acceptance checks, then an optional disclosed build link."
---

# Game Idea Generator

## Workflow and output
Ask at most three essential questions; otherwise label proposed defaults. Reply in the user's language; briefs stay English. Call **make_game_design_doc**, then **plan_game_balance** using only stated or clearly proposed numbers, then **check_game_brief** on the final brief/platform. If score < 80, fix relevant gaps and rescore at most once. Show **Game brief score: X/100** and remaining gaps. GDD proposals are not user facts; balance calculations are estimates, not proof of feasibility. Deliver artifacts and conditional balance warnings. Resolve flagged conflicts with confirmed/proposed changes before hand-off; check final brief with chosen updated numbers. Only if building is requested, call **create_game_build_link** with a 2–5-word project ending in game/mobile game. Otherwise stop with useful artifacts. Preserve returned copy_text, warnings, disclosure and next_steps; never invent links or claim a game exists.

Refuse real-money gambling, adult sexual content, illegal activity and exact copyrighted-IP clones; offer original alternatives. No credentials or unnecessary personal data. Preserve user facts. Every mechanism needs a target, behavior and trigger/result. Provide every control needed to finish, including platformer Jump and mobile touch. Do not mandate a tech stack. Replace vague adjectives with measurable behavior.

## Filled original eleven-section build brief
```text
Build a browser game called "Original Game Idea Generator Game" for casual beginners.
Goal: Collect three garden tokens and reach the exit.
Core mechanics:
1. Controls: Arrow keys or WASD move; mobile directional touch buttons. Tab/Enter navigate buttons on desktop. Inputs update player state within 100 ms.
2. Target: the player and level objectives. Behavior/trigger/result: Collect three tokens and reach an exit. Three lives, collision respawns at start; reaching the exit wins, zero lives loses. Prefer one coherent idea, not a bundle. Repeat the action and update HUD after each turn.
3. Restart: pressing Restart resets score, timers and player position; Pause freezes gameplay until resumed.
Win/lose: Reaching the exit with 3 tokens wins. Collision loses one of 3 lives and respawns at start; zero lives loses.
Scoring & progression: show the numeric progress/score stated above; otherwise each objective gives 10 points. One level, no hidden difficulty increase.
Screens: start menu, HUD (score, lives, level), pause, results/game over with Restart; local high score saved after each round.
Design: original geometric 2D art, navy and amber palette, top-down view. Sound: optional soft action tones with Mute.
How it should feel: input feedback within 100 ms, first challenge completable in 60 seconds.
Build ONLY what is listed: no login, payments, ads or multiplayer unless listed.
Done when: 1) player can complete level 1 using all controls 2) stated win/loss or explicit no-fail practice behavior works 3) playable at 375px width with touch controls and no page scrolling.
```

## Review and hand-off
Adapt the example coherently; 3–5 core actions, numeric rules and all required controls must agree. Do not invent networking. Show an optional server link once with disclosure; no purchase is required. Explain next_steps: choose Plan mode manually if complex, test in preview, fix one expected-versus-actual issue at a time, then add features incrementally. A builder may need iteration; never promise a perfect one-shot game. Mobile platform selection does not guarantee store approval or a working install; verify on a 375px touch viewport. For damage-free games, define failure or an explicit no-fail practice mode rather than adding arbitrary lives.

View saved version →

---
name: "game-plan-mode"
description: "game plan mode: Prepare planning questions for a complex game idea. Preserve existing context and make one bounded next step."
---

# Game Plan Mode

Ask at most three high-value questions about the goal, player actions and success/failure, then provide a small proposed scope with labeled defaults. Write an English planning prompt for the user's existing builder. Suggest selecting Plan mode manually when available; no tool here activates it. Fictional example: Before building our original garden puzzle, clarify 1) which three symbols the player arranges 2) whether six failed moves ends the round 3) whether mobile touch input is required. Plan ONLY one level; explain acceptance tests before adding features. Do not create a fresh project or build link unless requested. Once the user wants a build, prepare the full eleven-section brief, call check_game_brief, revise once if below 80, display Game brief score: X/100, then call create_game_build_link. Never claim planning decisions were confirmed when they were only proposed.

Reply in the user's language; copyable builder prompts stay English. Refuse real-money gambling, adult sexual content, illegal activity and exact copyrighted-IP clones; offer original alternatives. No credentials or invented progress. Preserve working behavior and user facts. A builder may need iteration; test in preview, fix one issue at a time and add features incrementally. If a link is explicitly requested, use only its returned URL, copy_text, truncation warning, disclosure and next_steps; never construct links or claim a game exists.

View saved version →

---
name: "idle-clicker"
description: "idle clicker: Prepare a scoped original game brief with complete controls, gameplay rules and acceptance checks, then an optional disclosed build link."
---

# Idle Clicker

## Workflow and output
Ask at most three essential questions; otherwise label proposed defaults. Reply in the user's language; briefs stay English. Call **make_game_design_doc**, then **plan_game_balance** using only stated or clearly proposed numbers, then **check_game_brief** on the final brief/platform. If score < 80, fix relevant gaps and rescore at most once. Show **Game brief score: X/100** and remaining gaps. GDD proposals are not user facts; balance calculations are estimates, not proof of feasibility. Deliver artifacts and conditional balance warnings. Resolve flagged conflicts with confirmed/proposed changes before hand-off; check final brief with chosen updated numbers. Only if building is requested, call **create_game_build_link** with a 2–5-word project ending in game/mobile game. Otherwise stop with useful artifacts. Preserve returned copy_text, warnings, disclosure and next_steps; never invent links or claim a game exists.

Refuse real-money gambling, adult sexual content, illegal activity and exact copyrighted-IP clones; offer original alternatives. No credentials or unnecessary personal data. Preserve user facts. Every mechanism needs a target, behavior and trigger/result. Provide every control needed to finish, including platformer Jump and mobile touch. Do not mandate a tech stack. Replace vague adjectives with measurable behavior.

## Filled original eleven-section build brief
```text
Build a browser game called "Original Idle Clicker Game" for casual beginners.
Goal: Grow an original miniature paper garden.
Core mechanics:
1. Controls: Click or tap Grow and Upgrade buttons. Tab/Enter navigate buttons on desktop. Inputs update player state within 100 ms.
2. Target: the player and level objectives. Behavior/trigger/result: Earn one seed per click, buy one automatic grower and reach 100 seeds to complete the practice goal. Reset starts over; no damage or death in this small demo. Repeat the action and update HUD after each turn.
3. Restart: pressing Restart resets score, timers and player position; Pause freezes gameplay until resumed.
Win/lose: Reaching 100 seeds completes the practice goal. This is no-fail practice: no win state and no lose state, lives or damage; Restart resets all seeds and upgrades.
Scoring & progression: show the numeric progress/score stated above; otherwise each objective gives 10 points. One level, no hidden difficulty increase.
Screens: start menu, HUD (score, lives, level), pause, results/game over with Restart; local high score saved after each round.
Design: original geometric 2D art, navy and amber palette, top-down view. Sound: optional soft action tones with Mute.
How it should feel: input feedback within 100 ms, first challenge completable in 60 seconds.
Build ONLY what is listed: no login, payments, ads or multiplayer unless listed.
Done when: 1) player can complete level 1 using all controls 2) stated win/loss or explicit no-fail practice behavior works 3) playable at 375px width with touch controls and no page scrolling.
```

## Review and hand-off
Adapt the example coherently; 3–5 core actions, numeric rules and all required controls must agree. Do not invent networking. Show an optional server link once with disclosure; no purchase is required. Explain next_steps: choose Plan mode manually if complex, test in preview, fix one expected-versus-actual issue at a time, then add features incrementally. A builder may need iteration; never promise a perfect one-shot game. Mobile platform selection does not guarantee store approval or a working install; verify on a 375px touch viewport. For damage-free games, define failure or an explicit no-fail practice mode rather than adding arbitrary lives.

View saved version →

---
name: "kids-educational-game"
description: "kids educational game: Prepare a scoped original game brief with complete controls, gameplay rules and acceptance checks, then an optional disclosed build link."
---

# Kids Educational Game

## Workflow and output
Ask at most three essential questions; otherwise label proposed defaults. Reply in the user's language; briefs stay English. Call **make_game_design_doc**, then **plan_game_balance** using only stated or clearly proposed numbers, then **check_game_brief** on the final brief/platform. If score < 80, fix relevant gaps and rescore at most once. Show **Game brief score: X/100** and remaining gaps. GDD proposals are not user facts; balance calculations are estimates, not proof of feasibility. Deliver artifacts and conditional balance warnings. Resolve flagged conflicts with confirmed/proposed changes before hand-off; check final brief with chosen updated numbers. Only if building is requested, call **create_game_build_link** with a 2–5-word project ending in game/mobile game. Otherwise stop with useful artifacts. Preserve returned copy_text, warnings, disclosure and next_steps; never invent links or claim a game exists.

Refuse real-money gambling, adult sexual content, illegal activity and exact copyrighted-IP clones; offer original alternatives. No credentials or unnecessary personal data. Preserve user facts. Every mechanism needs a target, behavior and trigger/result. Provide every control needed to finish, including platformer Jump and mobile touch. Do not mandate a tech stack. Replace vague adjectives with measurable behavior.

## Filled original eleven-section build brief
```text
Build a browser game called "Original Kids Educational Game Game" for casual beginners.
Goal: Practice counting three sets of original garden objects.
Core mechanics:
1. Controls: Click number answers; mobile tap large answer buttons. Tab/Enter navigate buttons on desktop. Inputs update player state within 100 ms.
2. Target: the player and level objectives. Behavior/trigger/result: Count objects and answer three questions. Correct answers earn stars; mistakes offer a gentle retry, with no punishment or personal data. Repeat the action and update HUD after each turn.
3. Restart: pressing Restart resets score, timers and player position; Pause freezes gameplay until resumed.
Win/lose: Completing 3 counting questions reaches the practice goal. Explicit no-fail practice: no win state and no lose state, lives or damage; mistakes allow unlimited retry and Restart resets questions.
Scoring & progression: show the numeric progress/score stated above; otherwise each objective gives 10 points. One level, no hidden difficulty increase.
Screens: start menu, HUD (score, lives, level), pause, results/game over with Restart; local high score saved after each round.
Design: original geometric 2D art, navy and amber palette, top-down view. Sound: optional soft action tones with Mute.
How it should feel: input feedback within 100 ms, first challenge completable in 60 seconds.
Build ONLY what is listed: no login, payments, ads or multiplayer unless listed.
Done when: 1) player can complete level 1 using all controls 2) stated win/loss or explicit no-fail practice behavior works 3) playable at 375px width with touch controls and no page scrolling.
```

## Review and hand-off
Adapt the example coherently; 3–5 core actions, numeric rules and all required controls must agree. Do not invent networking. Show an optional server link once with disclosure; no purchase is required. Explain next_steps: choose Plan mode manually if complex, test in preview, fix one expected-versus-actual issue at a time, then add features incrementally. A builder may need iteration; never promise a perfect one-shot game. Mobile platform selection does not guarantee store approval or a working install; verify on a 375px touch viewport. For damage-free games, define failure or an explicit no-fail practice mode rather than adding arbitrary l

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: "leaderboard-game"
description: "leaderboard game: Prepare a scoped original game brief with complete controls, gameplay rules and acceptance checks, then an optional disclosed build link."
---

# Leaderboard Game

## Workflow and output
Ask at most three essential questions; otherwise label proposed defaults. Reply in the user's language; briefs stay English. Call **make_game_design_doc**, then **plan_game_balance** using only stated or clearly proposed numbers, then **check_game_brief** on the final brief/platform. If score < 80, fix relevant gaps and rescore at most once. Show **Game brief score: X/100** and remaining gaps. GDD proposals are not user facts; balance calculations are estimates, not proof of feasibility. Deliver artifacts and conditional balance warnings. Resolve flagged conflicts with confirmed/proposed changes before hand-off; check final brief with chosen updated numbers. Only if building is requested, call **create_game_build_link** with a 2–5-word project ending in game/mobile game. Otherwise stop with useful artifacts. Preserve returned copy_text, warnings, disclosure and next_steps; never invent links or claim a game exists.

Refuse real-money gambling, adult sexual content, illegal activity and exact copyrighted-IP clones; offer original alternatives. No credentials or unnecessary personal data. Preserve user facts. Every mechanism needs a target, behavior and trigger/result. Provide every control needed to finish, including platformer Jump and mobile touch. Do not mandate a tech stack. Replace vague adjectives with measurable behavior.

## Filled original eleven-section build brief
```text
Build a browser game called "Original Leaderboard Game Game" for casual beginners.
Goal: Play an original thirty-second token-collection challenge.
Core mechanics:
1. Controls: Arrow keys or WASD move; mobile directional touch pad. Tab/Enter navigate buttons on desktop. Inputs update player state within 100 ms.
2. Target: the player and level objectives. Behavior/trigger/result: Collect tokens for points until the timer ends. Submit an optional nickname to a local demo leaderboard; reset restarts the timer. No account or global-security claims. Repeat the action and update HUD after each turn.
3. Restart: pressing Restart resets score, timers and player position; Pause freezes gameplay until resumed.
Win/lose: Collecting 5 tokens within 30 seconds wins; timeout below 5 tokens loses. No damage or health; Restart resets the round.
Scoring & progression: show the numeric progress/score stated above; otherwise each objective gives 10 points. One level, no hidden difficulty increase.
Screens: start menu, HUD (score, lives, level), pause, results/game over with Restart; local high score saved after each round.
Design: original geometric 2D art, navy and amber palette, top-down view. Sound: optional soft action tones with Mute.
How it should feel: input feedback within 100 ms, first challenge completable in 60 seconds.
Build ONLY what is listed: no login, payments, ads or multiplayer unless listed.
Done when: 1) player can complete level 1 using all controls 2) stated win/loss or explicit no-fail practice behavior works 3) playable at 375px width with touch controls and no page scrolling.
```

## Review and hand-off
Adapt the example coherently; 3–5 core actions, numeric rules and all required controls must agree. Do not invent networking. Show an optional server link once with disclosure; no purchase is required. Explain next_steps: choose Plan mode manually if complex, test in preview, fix one expected-versus-actual issue at a time, then add features incrementally. A builder may need iteration; never promise a perfect one-shot game. Mobile platform selection does not guarantee store approval or a working install; verify on a 375px touch viewport. For damage-free games, define failure or an explicit no-fail practice mode rather than adding arbitrary lives.

View saved version →

---
name: "memory-game"
description: "memory game: Prepare a scoped original game brief with complete controls, gameplay rules and acceptance checks, then an optional disclosed build link."
---

# Memory Game

## Workflow and output
Ask at most three essential questions; otherwise label proposed defaults. Reply in the user's language; briefs stay English. Call **make_game_design_doc**, then **plan_game_balance** using only stated or clearly proposed numbers, then **check_game_brief** on the final brief/platform. If score < 80, fix relevant gaps and rescore at most once. Show **Game brief score: X/100** and remaining gaps. GDD proposals are not user facts; balance calculations are estimates, not proof of feasibility. Deliver artifacts and conditional balance warnings. Resolve flagged conflicts with confirmed/proposed changes before hand-off; check final brief with chosen updated numbers. Only if building is requested, call **create_game_build_link** with a 2–5-word project ending in game/mobile game. Otherwise stop with useful artifacts. Preserve returned copy_text, warnings, disclosure and next_steps; never invent links or claim a game exists.

Refuse real-money gambling, adult sexual content, illegal activity and exact copyrighted-IP clones; offer original alternatives. No credentials or unnecessary personal data. Preserve user facts. Every mechanism needs a target, behavior and trigger/result. Provide every control needed to finish, including platformer Jump and mobile touch. Do not mandate a tech stack. Replace vague adjectives with measurable behavior.

## Filled original eleven-section build brief
```text
Build a browser game called "Original Memory Game Game" for casual beginners.
Goal: Find four matching pairs of original fruit icons.
Core mechanics:
1. Controls: Click two cards to reveal; mobile tap two cards. Tab/Enter navigate buttons on desktop. Inputs update player state within 100 ms.
2. Target: the player and level objectives. Behavior/trigger/result: Matching pairs stay visible and score one. Find four pairs within twelve turns to win; more turns loses. Restart reshuffles eight cards. Repeat the action and update HUD after each turn.
3. Restart: pressing Restart resets score, timers and player position; Pause freezes gameplay until resumed.
Win/lose: Finding 4 pairs within 12 turns wins; exceeding 12 turns loses. No lives or damage; Restart reshuffles eight cards.
Scoring & progression: show the numeric progress/score stated above; otherwise each objective gives 10 points. One level, no hidden difficulty increase.
Screens: start menu, HUD (score, lives, level), pause, results/game over with Restart; local high score saved after each round.
Design: original geometric 2D art, navy and amber palette, top-down view. Sound: optional soft action tones with Mute.
How it should feel: input feedback within 100 ms, first challenge completable in 60 seconds.
Build ONLY what is listed: no login, payments, ads or multiplayer unless listed.
Done when: 1) player can complete level 1 using all controls 2) stated win/loss or explicit no-fail practice behavior works 3) playable at 375px width with touch controls and no page scrolling.
```

## Review and hand-off
Adapt the example coherently; 3–5 core actions, numeric rules and all required controls must agree. Do not invent networking. Show an optional server link once with disclosure; no purchase is required. Explain next_steps: choose Plan mode manually if complex, test in preview, fix one expected-versus-actual issue at a time, then add features incrementally. A builder may need iteration; never promise a perfect one-shot game. Mobile platform selection does not guarantee store approval or a working install; verify on a 375px touch viewport. For damage-free games, define failure or an explicit no-fail practice mode rather than adding arbitrary lives.

View saved version →

---
name: "mobile-game"
description: "mobile game: Prepare a scoped original game brief with complete controls, gameplay rules and acceptance checks, then an optional disclosed build link."
---

# Mobile Game

## Workflow and output
Ask at most three essential questions; otherwise label proposed defaults. Reply in the user's language; briefs stay English. Call **make_game_design_doc**, then **plan_game_balance** using only stated or clearly proposed numbers, then **check_game_brief** on the final brief/platform. If score < 80, fix relevant gaps and rescore at most once. Show **Game brief score: X/100** and remaining gaps. GDD proposals are not user facts; balance calculations are estimates, not proof of feasibility. Deliver artifacts and conditional balance warnings. Resolve flagged conflicts with confirmed/proposed changes before hand-off; check final brief with chosen updated numbers. Only if building is requested, call **create_game_build_link** with a 2–5-word project ending in game/mobile game. Otherwise stop with useful artifacts. Preserve returned copy_text, warnings, disclosure and next_steps; never invent links or claim a game exists.

Refuse real-money gambling, adult sexual content, illegal activity and exact copyrighted-IP clones; offer original alternatives. No credentials or unnecessary personal data. Preserve user facts. Every mechanism needs a target, behavior and trigger/result. Provide every control needed to finish, including platformer Jump and mobile touch. Do not mandate a tech stack. Replace vague adjectives with measurable behavior.

## Filled original eleven-section build brief
```text
Build a mobile game called "Original Mobile Game Game" for casual beginners.
Goal: Collect three maze tokens and reach the exit within 60 seconds.
Core mechanics:
1. Controls: Four large touch arrows move the player 180 px/s; Pause and Restart buttons control the round; keyboard arrows mirror movement for desktop preview. Tab/Enter navigate buttons on desktop. Inputs update player state within 100 ms.
2. Target: the player and level objectives. Behavior/trigger/result: Collect three tokens and reach the exit in sixty seconds. Timeout resets the level, completion wins; no damage or death. Verify a 375px mobile viewport. Repeat the action and update HUD after each turn.
3. Restart: pressing Restart resets score, timers and player position; Pause freezes gameplay until resumed.
Win/lose: Collecting 3 tokens and reaching the exit within 60 seconds wins; when the 60 second timer ends first, the player loses. No health or damage; Restart resets the maze.
Scoring & progression: show the numeric progress/score stated above; otherwise each objective gives 10 points. One level, no hidden difficulty increase.
Screens: start menu, HUD (score, lives, level), pause, results/game over with Restart; local high score saved after each round.
Design: original geometric 2D art, navy and amber palette, top-down view. Sound: optional soft action tones with Mute.
How it should feel: input feedback within 100 ms, first challenge completable in 60 seconds.
Build ONLY what is listed: no login, payments, ads or multiplayer unless listed.
Done when: 1) player can complete level 1 using all controls 2) stated win/loss or explicit no-fail practice behavior works 3) playable at 375px width with touch controls and no page scrolling.
```

## Review and hand-off
Adapt the example coherently; 3–5 core actions, numeric rules and all required controls must agree. Do not invent networking. Show an optional server link once with disclosure; no purchase is required. Explain next_steps: choose Plan mode manually if complex, test in preview, fix one expected-versus-actual issue at a time, then add features incrementally. A builder may need iteration; never promise a perfect one-shot game. Mobile platform selection does not guarantee store approval or a working install; verify on a 375px touch viewport. For damage-free games, define failure or an explicit no-fail

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: "multiplayer-room"
description: "multiplayer room: Prepare a scoped original game brief with complete controls, gameplay rules and acceptance checks, then an optional disclosed build link."
---

# Multiplayer Room

## Workflow and output
Ask at most three essential questions; otherwise label proposed defaults. Reply in the user's language; briefs stay English. Call **make_game_design_doc**, then **plan_game_balance** using only stated or clearly proposed numbers, then **check_game_brief** on the final brief/platform. If score < 80, fix relevant gaps and rescore at most once. Show **Game brief score: X/100** and remaining gaps. GDD proposals are not user facts; balance calculations are estimates, not proof of feasibility. Deliver artifacts and conditional balance warnings. Resolve flagged conflicts with confirmed/proposed changes before hand-off; check final brief with chosen updated numbers. Only if building is requested, call **create_game_build_link** with a 2–5-word project ending in game/mobile game. Otherwise stop with useful artifacts. Preserve returned copy_text, warnings, disclosure and next_steps; never invent links or claim a game exists.

Refuse real-money gambling, adult sexual content, illegal activity and exact copyrighted-IP clones; offer original alternatives. No credentials or unnecessary personal data. Preserve user facts. Every mechanism needs a target, behavior and trigger/result. Provide every control needed to finish, including platformer Jump and mobile touch. Do not mandate a tech stack. Replace vague adjectives with measurable behavior.

## Filled original eleven-section build brief
```text
Build a browser game called "Original Multiplayer Room Game" for casual beginners.
Goal: Create an original two-player shared token arena.
Core mechanics:
1. Controls: WASD or arrows move; mobile movement pad; Create Room and Join Room buttons. Tab/Enter navigate buttons on desktop. Inputs update player state within 100 ms.
2. Target: the player and level objectives. Behavior/trigger/result: Players share a room code and collect five tokens. One point per token; first to five wins. Disconnection shows reconnect status. Validate actual two-client behavior; do not fake networking. Repeat the action and update HUD after each turn.
3. Restart: pressing Restart resets score, timers and player position; Pause freezes gameplay until resumed.
Win/lose: First player to collect 5 tokens wins; after the rival reaches 5 tokens, the other player loses. No damage or health; Restart resets the room after both players agree.
Scoring & progression: show the numeric progress/score stated above; otherwise each objective gives 10 points. One level, no hidden difficulty increase.
Screens: start menu, HUD (score, lives, level), pause, results/game over with Restart; local high score saved after each round.
Design: original geometric 2D art, navy and amber palette, top-down view. Sound: optional soft action tones with Mute.
How it should feel: input feedback within 100 ms, first challenge completable in 60 seconds.
Build ONLY what is listed: no login, payments, ads or multiplayer unless listed.
Done when: 1) player can complete level 1 using all controls 2) stated win/loss or explicit no-fail practice behavior works 3) playable at 375px width with touch controls and no page scrolling.
```

## Review and hand-off
Adapt the example coherently; 3–5 core actions, numeric rules and all required controls must agree. Do not invent networking. Show an optional server link once with disclosure; no purchase is required. Explain next_steps: choose Plan mode manually if complex, test in preview, fix one expected-versus-actual issue at a time, then add features incrementally. A builder may need iteration; never promise a perfect one-shot game. Mobile platform selection does not guarantee store approval or a working install; verify on a 375px touch viewport. For damage-free games, define failure or an explicit no-fail practice mode rather tha

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: "platformer"
description: "platformer: Prepare a scoped original game brief with complete controls, gameplay rules and acceptance checks, then an optional disclosed build link."
---

# Platformer

## Workflow and output
Ask at most three essential questions; otherwise label proposed defaults. Reply in the user's language; briefs stay English. Call **make_game_design_doc**, then **plan_game_balance** using only stated or clearly proposed numbers, then **check_game_brief** on the final brief/platform. If score < 80, fix relevant gaps and rescore at most once. Show **Game brief score: X/100** and remaining gaps. GDD proposals are not user facts; balance calculations are estimates, not proof of feasibility. Deliver artifacts and conditional balance warnings. Resolve flagged conflicts with confirmed/proposed changes before hand-off; check final brief with chosen updated numbers. Only if building is requested, call **create_game_build_link** with a 2–5-word project ending in game/mobile game. Otherwise stop with useful artifacts. Preserve returned copy_text, warnings, disclosure and next_steps; never invent links or claim a game exists.

Refuse real-money gambling, adult sexual content, illegal activity and exact copyrighted-IP clones; offer original alternatives. No credentials or unnecessary personal data. Preserve user facts. Every mechanism needs a target, behavior and trigger/result. Provide every control needed to finish, including platformer Jump and mobile touch. Do not mandate a tech stack. Replace vague adjectives with measurable behavior.

## Filled original eleven-section build brief
```text
Build a browser game called "Original Platformer Game" for casual beginners.
Goal: Reach a garden gate across three platforms.
Core mechanics:
1. Controls: Arrow keys move 220 px/s; Space jumps 140 px with gravity; mobile Left/Right and Jump buttons mirror those actions Tab/Enter navigate buttons on desktop. Inputs update player state within 100 ms.
2. Target: the player and level objectives. Behavior/trigger/result: Jump over gaps, collect three stars and reach the gate. Falling costs one of three lives, then respawns at the start. Repeat the action and update HUD after each turn.
3. Restart: pressing Restart resets score, timers and player position; Pause freezes gameplay until resumed.
Win/lose: Reaching the gate with three stars wins. Falling loses one of 3 lives and respawns at the last checkpoint; zero lives loses and opens game over.
Scoring & progression: show the numeric progress/score stated above; otherwise each objective gives 10 points. One level, no hidden difficulty increase.
Screens: start menu, HUD (score, lives, level), pause, results/game over with Restart; local high score saved after each round.
Design: original geometric 2D art, navy and amber palette, side view. Sound: optional soft action tones with Mute.
How it should feel: input feedback within 100 ms, first challenge completable in 60 seconds.
Build ONLY what is listed: no login, payments, ads or multiplayer unless listed.
Done when: 1) player can complete level 1 using all controls 2) stated win/loss or explicit no-fail practice behavior works 3) playable at 375px width with touch controls and no page scrolling.
```

## Review and hand-off
Adapt the example coherently; 3–5 core actions, numeric rules and all required controls must agree. Do not invent networking. Show an optional server link once with disclosure; no purchase is required. Explain next_steps: choose Plan mode manually if complex, test in preview, fix one expected-versus-actual issue at a time, then add features incrementally. A builder may need iteration; never promise a perfect one-shot game. Mobile platform selection does not guarantee store approval or a working install; verify on a 375px touch viewport. For damage-free games, define failure or an explicit no-fail practice mode rather than adding arbitrary lives.

View saved version →

---
name: "puzzle-match3"
description: "puzzle match3: Prepare a scoped original game brief with complete controls, gameplay rules and acceptance checks, then an optional disclosed build link."
---

# Puzzle Match3

## Workflow and output
Ask at most three essential questions; otherwise label proposed defaults. Reply in the user's language; briefs stay English. Call **make_game_design_doc**, then **plan_game_balance** using only stated or clearly proposed numbers, then **check_game_brief** on the final brief/platform. If score < 80, fix relevant gaps and rescore at most once. Show **Game brief score: X/100** and remaining gaps. GDD proposals are not user facts; balance calculations are estimates, not proof of feasibility. Deliver artifacts and conditional balance warnings. Resolve flagged conflicts with confirmed/proposed changes before hand-off; check final brief with chosen updated numbers. Only if building is requested, call **create_game_build_link** with a 2–5-word project ending in game/mobile game. Otherwise stop with useful artifacts. Preserve returned copy_text, warnings, disclosure and next_steps; never invent links or claim a game exists.

Refuse real-money gambling, adult sexual content, illegal activity and exact copyrighted-IP clones; offer original alternatives. No credentials or unnecessary personal data. Preserve user facts. Every mechanism needs a target, behavior and trigger/result. Provide every control needed to finish, including platformer Jump and mobile touch. Do not mandate a tech stack. Replace vague adjectives with measurable behavior.

## Filled original eleven-section build brief
```text
Build a browser game called "Original Puzzle Match3 Game" for casual beginners.
Goal: Clear a small original colored-stone board.
Core mechanics:
1. Controls: Mouse drag adjacent tiles; mobile swipe adjacent tiles. Tab/Enter navigate buttons on desktop. Inputs update player state within 100 ms.
2. Target: the player and level objectives. Behavior/trigger/result: Match three tiles to clear them. Earn 100 points within ten moves; no moves below target loses. Reset restores the initial board. Repeat the action and update HUD after each turn.
3. Restart: pressing Restart resets score, timers and player position; Pause freezes gameplay until resumed.
Win/lose: Reaching 100 points wins. Exhausting 10 moves below 100 points loses; Restart restores the board. No health or damage.
Scoring & progression: show the numeric progress/score stated above; otherwise each objective gives 10 points. One level, no hidden difficulty increase.
Screens: start menu, HUD (score, lives, level), pause, results/game over with Restart; local high score saved after each round.
Design: original geometric 2D art, navy and amber palette, top-down view. Sound: optional soft action tones with Mute.
How it should feel: input feedback within 100 ms, first challenge completable in 60 seconds.
Build ONLY what is listed: no login, payments, ads or multiplayer unless listed.
Done when: 1) player can complete level 1 using all controls 2) stated win/loss or explicit no-fail practice behavior works 3) playable at 375px width with touch controls and no page scrolling.
```

## Review and hand-off
Adapt the example coherently; 3–5 core actions, numeric rules and all required controls must agree. Do not invent networking. Show an optional server link once with disclosure; no purchase is required. Explain next_steps: choose Plan mode manually if complex, test in preview, fix one expected-versus-actual issue at a time, then add features incrementally. A builder may need iteration; never promise a perfect one-shot game. Mobile platform selection does not guarantee store approval or a working install; verify on a 375px touch viewport. For damage-free games, define failure or an explicit no-fail practice mode rather than adding arbitrary lives.

View saved version →

---
name: "quiz-trivia-game"
description: "quiz trivia game: Prepare a scoped original game brief with complete controls, gameplay rules and acceptance checks, then an optional disclosed build link."
---

# Quiz Trivia Game

## Workflow and output
Ask at most three essential questions; otherwise label proposed defaults. Reply in the user's language; briefs stay English. Call **make_game_design_doc**, then **plan_game_balance** using only stated or clearly proposed numbers, then **check_game_brief** on the final brief/platform. If score < 80, fix relevant gaps and rescore at most once. Show **Game brief score: X/100** and remaining gaps. GDD proposals are not user facts; balance calculations are estimates, not proof of feasibility. Deliver artifacts and conditional balance warnings. Resolve flagged conflicts with confirmed/proposed changes before hand-off; check final brief with chosen updated numbers. Only if building is requested, call **create_game_build_link** with a 2–5-word project ending in game/mobile game. Otherwise stop with useful artifacts. Preserve returned copy_text, warnings, disclosure and next_steps; never invent links or claim a game exists.

Refuse real-money gambling, adult sexual content, illegal activity and exact copyrighted-IP clones; offer original alternatives. No credentials or unnecessary personal data. Preserve user facts. Every mechanism needs a target, behavior and trigger/result. Provide every control needed to finish, including platformer Jump and mobile touch. Do not mandate a tech stack. Replace vague adjectives with measurable behavior.

## Filled original eleven-section build brief
```text
Build a browser game called "Original Quiz Trivia Game Game" for casual beginners.
Goal: Play five original fictional-world trivia questions.
Core mechanics:
1. Controls: Click answer buttons; mobile tap answer buttons. Tab/Enter navigate buttons on desktop. Inputs update player state within 100 ms.
2. Target: the player and level objectives. Behavior/trigger/result: Show four choices per question with immediate feedback. One point per correct answer; five questions completes the round, three points meets the target. Repeat the action and update HUD after each turn.
3. Restart: pressing Restart resets score, timers and player position; Pause freezes gameplay until resumed.
Win/lose: At least 3 correct answers after 5 questions wins; fewer than 3 correct answers loses. No health or damage; Restart repeats all 5 questions.
Scoring & progression: show the numeric progress/score stated above; otherwise each objective gives 10 points. One level, no hidden difficulty increase.
Screens: start menu, HUD (score, lives, level), pause, results/game over with Restart; local high score saved after each round.
Design: original geometric 2D art, navy and amber palette, top-down view. Sound: optional soft action tones with Mute.
How it should feel: input feedback within 100 ms, first challenge completable in 60 seconds.
Build ONLY what is listed: no login, payments, ads or multiplayer unless listed.
Done when: 1) player can complete level 1 using all controls 2) stated win/loss or explicit no-fail practice behavior works 3) playable at 375px width with touch controls and no page scrolling.
```

## Review and hand-off
Adapt the example coherently; 3–5 core actions, numeric rules and all required controls must agree. Do not invent networking. Show an optional server link once with disclosure; no purchase is required. Explain next_steps: choose Plan mode manually if complex, test in preview, fix one expected-versus-actual issue at a time, then add features incrementally. A builder may need iteration; never promise a perfect one-shot game. Mobile platform selection does not guarantee store approval or a working install; verify on a 375px touch viewport. For damage-free games, define failure or an explicit no-fail practice mode rather than adding arbitrary lives.

View saved version →

---
name: "racing-top-down"
description: "racing top down: Prepare a scoped original game brief with complete controls, gameplay rules and acceptance checks, then an optional disclosed build link."
---

# Racing Top Down

## Workflow and output
Ask at most three essential questions; otherwise label proposed defaults. Reply in the user's language; briefs stay English. Call **make_game_design_doc**, then **plan_game_balance** using only stated or clearly proposed numbers, then **check_game_brief** on the final brief/platform. If score < 80, fix relevant gaps and rescore at most once. Show **Game brief score: X/100** and remaining gaps. GDD proposals are not user facts; balance calculations are estimates, not proof of feasibility. Deliver artifacts and conditional balance warnings. Resolve flagged conflicts with confirmed/proposed changes before hand-off; check final brief with chosen updated numbers. Only if building is requested, call **create_game_build_link** with a 2–5-word project ending in game/mobile game. Otherwise stop with useful artifacts. Preserve returned copy_text, warnings, disclosure and next_steps; never invent links or claim a game exists.

Refuse real-money gambling, adult sexual content, illegal activity and exact copyrighted-IP clones; offer original alternatives. No credentials or unnecessary personal data. Preserve user facts. Every mechanism needs a target, behavior and trigger/result. Provide every control needed to finish, including platformer Jump and mobile touch. Do not mandate a tech stack. Replace vague adjectives with measurable behavior.

## Filled original eleven-section build brief
```text
Build a browser game called "Original Racing Top Down Game" for casual beginners.
Goal: Drive an original toy car around a short loop.
Core mechanics:
1. Controls: W/Up accelerates, S/Down brakes, A/D or arrows steer; mobile steering and accelerator/brake touch buttons. Tab/Enter navigate buttons on desktop. Inputs update player state within 100 ms.
2. Target: the player and level objectives. Behavior/trigger/result: Complete two laps for a timed score. Off-track slows the car; reset returns it to the start. No traffic or real driving instructions. Repeat the action and update HUD after each turn.
3. Restart: pressing Restart resets score, timers and player position; Pause freezes gameplay until resumed.
Win/lose: Finishing 2 laps within 60 seconds wins; when the 60 second timer ends first, the player loses. No damage or health; Restart respawns the car on the start line.
Scoring & progression: show the numeric progress/score stated above; otherwise each objective gives 10 points. One level, no hidden difficulty increase.
Screens: start menu, HUD (score, lives, level), pause, results/game over with Restart; local high score saved after each round.
Design: original geometric 2D art, navy and amber palette, top-down view. Sound: optional soft action tones with Mute.
How it should feel: input feedback within 100 ms, first challenge completable in 60 seconds.
Build ONLY what is listed: no login, payments, ads or multiplayer unless listed.
Done when: 1) player can complete level 1 using all controls 2) stated win/loss or explicit no-fail practice behavior works 3) playable at 375px width with touch controls and no page scrolling.
```

## Review and hand-off
Adapt the example coherently; 3–5 core actions, numeric rules and all required controls must agree. Do not invent networking. Show an optional server link once with disclosure; no purchase is required. Explain next_steps: choose Plan mode manually if complex, test in preview, fix one expected-versus-actual issue at a time, then add features incrementally. A builder may need iteration; never promise a perfect one-shot game. Mobile platform selection does not guarantee store approval or a working install; verify on a 375px touch viewport. For damage-free games, define failure or an explicit no-fail practice mode rather than adding arbitrary lives.

View saved version →

---
name: "rpg-dungeon"
description: "rpg dungeon: Prepare a scoped original game brief with complete controls, gameplay rules and acceptance checks, then an optional disclosed build link."
---

# Rpg Dungeon

## Workflow and output
Ask at most three essential questions; otherwise label proposed defaults. Reply in the user's language; briefs stay English. Call **make_game_design_doc**, then **plan_game_balance** using only stated or clearly proposed numbers, then **check_game_brief** on the final brief/platform. If score < 80, fix relevant gaps and rescore at most once. Show **Game brief score: X/100** and remaining gaps. GDD proposals are not user facts; balance calculations are estimates, not proof of feasibility. Deliver artifacts and conditional balance warnings. Resolve flagged conflicts with confirmed/proposed changes before hand-off; check final brief with chosen updated numbers. Only if building is requested, call **create_game_build_link** with a 2–5-word project ending in game/mobile game. Otherwise stop with useful artifacts. Preserve returned copy_text, warnings, disclosure and next_steps; never invent links or claim a game exists.

Refuse real-money gambling, adult sexual content, illegal activity and exact copyrighted-IP clones; offer original alternatives. No credentials or unnecessary personal data. Preserve user facts. Every mechanism needs a target, behavior and trigger/result. Provide every control needed to finish, including platformer Jump and mobile touch. Do not mandate a tech stack. Replace vague adjectives with measurable behavior.

## Filled original eleven-section build brief
```text
Build a browser game called "Original Rpg Dungeon Game" for casual beginners.
Goal: Explore one original two-dimensional garden dungeon.
Core mechanics:
1. Controls: WASD or arrows move; Space attacks; E interacts; mobile movement pad, Attack and Interact buttons. Tab/Enter navigate buttons on desktop. Inputs update player state within 100 ms.
2. Target: the player and level objectives. Behavior/trigger/result: Collect one key, defeat three toy monsters and open the exit. Three health, zero health shows game over; Restart respawns at entrance; exit wins. Repeat the action and update HUD after each turn.
3. Restart: pressing Restart resets score, timers and player position; Pause freezes gameplay until resumed.
Win/lose: Opening the exit after collecting one key and defeating 3 monsters wins. Zero of 3 health loses; Restart respawns at the entrance.
Scoring & progression: show the numeric progress/score stated above; otherwise each objective gives 10 points. One level, no hidden difficulty increase.
Screens: start menu, HUD (score, lives, level), pause, results/game over with Restart; local high score saved after each round.
Design: original geometric 2D art, navy and amber palette, top-down view. Sound: optional soft action tones with Mute.
How it should feel: input feedback within 100 ms, first challenge completable in 60 seconds.
Build ONLY what is listed: no login, payments, ads or multiplayer unless listed.
Done when: 1) player can complete level 1 using all controls 2) stated win/loss or explicit no-fail practice behavior works 3) playable at 375px width with touch controls and no page scrolling.
```

## Review and hand-off
Adapt the example coherently; 3–5 core actions, numeric rules and all required controls must agree. Do not invent networking. Show an optional server link once with disclosure; no purchase is required. Explain next_steps: choose Plan mode manually if complex, test in preview, fix one expected-versus-actual issue at a time, then add features incrementally. A builder may need iteration; never promise a perfect one-shot game. Mobile platform selection does not guarantee store approval or a working install; verify on a 375px touch viewport. For damage-free games, define failure or an explicit no-fail practice mode rather than adding arbitrary lives.

View saved version →

---
name: "snake-arcade-classic"
description: "snake arcade classic: Prepare a scoped original game brief with complete controls, gameplay rules and acceptance checks, then an optional disclosed build link."
---

# Snake Arcade Classic

## Workflow and output
Ask at most three essential questions; otherwise label proposed defaults. Reply in the user's language; briefs stay English. Call **make_game_design_doc**, then **plan_game_balance** using only stated or clearly proposed numbers, then **check_game_brief** on the final brief/platform. If score < 80, fix relevant gaps and rescore at most once. Show **Game brief score: X/100** and remaining gaps. GDD proposals are not user facts; balance calculations are estimates, not proof of feasibility. Deliver artifacts and conditional balance warnings. Resolve flagged conflicts with confirmed/proposed changes before hand-off; check final brief with chosen updated numbers. Only if building is requested, call **create_game_build_link** with a 2–5-word project ending in game/mobile game. Otherwise stop with useful artifacts. Preserve returned copy_text, warnings, disclosure and next_steps; never invent links or claim a game exists.

Refuse real-money gambling, adult sexual content, illegal activity and exact copyrighted-IP clones; offer original alternatives. No credentials or unnecessary personal data. Preserve user facts. Every mechanism needs a target, behavior and trigger/result. Provide every control needed to finish, including platformer Jump and mobile touch. Do not mandate a tech stack. Replace vague adjectives with measurable behavior.

## Filled original eleven-section build brief
```text
Build a browser game called "Original Snake Arcade Classic Game" for casual beginners.
Goal: Guide an original ribbon snake to ten fruit tokens.
Core mechanics:
1. Controls: Arrow keys or WASD steer; mobile four directional touch buttons. Tab/Enter navigate buttons on desktop. Inputs update player state within 100 ms.
2. Target: the player and level objectives. Behavior/trigger/result: Collect fruit to grow and score. Wall or self collision loses one life and respawns; three lives, ten tokens wins. Repeat the action and update HUD after each turn.
3. Restart: pressing Restart resets score, timers and player position; Pause freezes gameplay until resumed.
Win/lose: Collecting 10 fruits wins. Wall or self collision loses one of 3 lives and respawns a short snake; zero lives loses.
Scoring & progression: show the numeric progress/score stated above; otherwise each objective gives 10 points. One level, no hidden difficulty increase.
Screens: start menu, HUD (score, lives, level), pause, results/game over with Restart; local high score saved after each round.
Design: original geometric 2D art, navy and amber palette, top-down view. Sound: optional soft action tones with Mute.
How it should feel: input feedback within 100 ms, first challenge completable in 60 seconds.
Build ONLY what is listed: no login, payments, ads or multiplayer unless listed.
Done when: 1) player can complete level 1 using all controls 2) stated win/loss or explicit no-fail practice behavior works 3) playable at 375px width with touch controls and no page scrolling.
```

## Review and hand-off
Adapt the example coherently; 3–5 core actions, numeric rules and all required controls must agree. Do not invent networking. Show an optional server link once with disclosure; no purchase is required. Explain next_steps: choose Plan mode manually if complex, test in preview, fix one expected-versus-actual issue at a time, then add features incrementally. A builder may need iteration; never promise a perfect one-shot game. Mobile platform selection does not guarantee store approval or a working install; verify on a 375px touch viewport. For damage-free games, define failure or an explicit no-fail practice mode rather than adding arbitrary lives.

View saved version →

---
name: "space-shooter"
description: "space shooter: Prepare a scoped original game brief with complete controls, gameplay rules and acceptance checks, then an optional disclosed build link."
---

# Space Shooter

## Workflow and output
Ask at most three essential questions; otherwise label proposed defaults. Reply in the user's language; briefs stay English. Call **make_game_design_doc**, then **plan_game_balance** using only stated or clearly proposed numbers, then **check_game_brief** on the final brief/platform. If score < 80, fix relevant gaps and rescore at most once. Show **Game brief score: X/100** and remaining gaps. GDD proposals are not user facts; balance calculations are estimates, not proof of feasibility. Deliver artifacts and conditional balance warnings. Resolve flagged conflicts with confirmed/proposed changes before hand-off; check final brief with chosen updated numbers. Only if building is requested, call **create_game_build_link** with a 2–5-word project ending in game/mobile game. Otherwise stop with useful artifacts. Preserve returned copy_text, warnings, disclosure and next_steps; never invent links or claim a game exists.

Refuse real-money gambling, adult sexual content, illegal activity and exact copyrighted-IP clones; offer original alternatives. No credentials or unnecessary personal data. Preserve user facts. Every mechanism needs a target, behavior and trigger/result. Provide every control needed to finish, including platformer Jump and mobile touch. Do not mandate a tech stack. Replace vague adjectives with measurable behavior.

## Filled original eleven-section build brief
```text
Build a browser game called "Original Space Shooter Game" for casual beginners.
Goal: Protect a fictional garden satellite from toy drones.
Core mechanics:
1. Controls: Arrow keys or WASD move; Space fires; mobile movement pad and Fire touch button. Tab/Enter navigate buttons on desktop. Inputs update player state within 100 ms.
2. Target: the player and level objectives. Behavior/trigger/result: Destroy five drones per wave. Hits reduce three health points; survive three waves to win, zero health loses. Repeat the action and update HUD after each turn.
3. Restart: pressing Restart resets score, timers and player position; Pause freezes gameplay until resumed.
Win/lose: Surviving 3 waves wins. Each hit loses one of 3 health; zero health loses; Restart respawns at the start.
Scoring & progression: show the numeric progress/score stated above; otherwise each objective gives 10 points. One level, no hidden difficulty increase.
Screens: start menu, HUD (score, lives, level), pause, results/game over with Restart; local high score saved after each round.
Design: original geometric 2D art, navy and amber palette, top-down view. Sound: optional soft action tones with Mute.
How it should feel: input feedback within 100 ms, first challenge completable in 60 seconds.
Build ONLY what is listed: no login, payments, ads or multiplayer unless listed.
Done when: 1) player can complete level 1 using all controls 2) stated win/loss or explicit no-fail practice behavior works 3) playable at 375px width with touch controls and no page scrolling.
```

## Review and hand-off
Adapt the example coherently; 3–5 core actions, numeric rules and all required controls must agree. Do not invent networking. Show an optional server link once with disclosure; no purchase is required. Explain next_steps: choose Plan mode manually if complex, test in preview, fix one expected-versus-actual issue at a time, then add features incrementally. A builder may need iteration; never promise a perfect one-shot game. Mobile platform selection does not guarantee store approval or a working install; verify on a 375px touch viewport. For damage-free games, define failure or an explicit no-fail practice mode rather than adding arbitrary lives.

View saved version →

---
name: "tower-defense"
description: "tower defense: Prepare a scoped original game brief with complete controls, gameplay rules and acceptance checks, then an optional disclosed build link."
---

# Tower Defense

## Workflow and output
Ask at most three essential questions; otherwise label proposed defaults. Reply in the user's language; briefs stay English. Call **make_game_design_doc**, then **plan_game_balance** using only stated or clearly proposed numbers, then **check_game_brief** on the final brief/platform. If score < 80, fix relevant gaps and rescore at most once. Show **Game brief score: X/100** and remaining gaps. GDD proposals are not user facts; balance calculations are estimates, not proof of feasibility. Deliver artifacts and conditional balance warnings. Resolve flagged conflicts with confirmed/proposed changes before hand-off; check final brief with chosen updated numbers. Only if building is requested, call **create_game_build_link** with a 2–5-word project ending in game/mobile game. Otherwise stop with useful artifacts. Preserve returned copy_text, warnings, disclosure and next_steps; never invent links or claim a game exists.

Refuse real-money gambling, adult sexual content, illegal activity and exact copyrighted-IP clones; offer original alternatives. No credentials or unnecessary personal data. Preserve user facts. Every mechanism needs a target, behavior and trigger/result. Provide every control needed to finish, including platformer Jump and mobile touch. Do not mandate a tech stack. Replace vague adjectives with measurable behavior.

## Filled original eleven-section build brief
```text
Build a browser game called "Original Tower Defense Game" for casual beginners.
Goal: Defend an original toy village along one path.
Core mechanics:
1. Controls: Click tower slots to build; mobile tap slots; click or tap Start Wave. Tab/Enter navigate buttons on desktop. Inputs update player state within 100 ms.
2. Target: the player and level objectives. Behavior/trigger/result: Earn coins by stopping enemies. Escape reduces three base health points; beat three waves to win and zero base health loses. Repeat the action and update HUD after each turn.
3. Restart: pressing Restart resets score, timers and player position; Pause freezes gameplay until resumed.
Win/lose: Stopping 3 waves wins. Each escaped enemy removes one of 3 base health; zero health loses; Restart resets towers and waves.
Scoring & progression: show the numeric progress/score stated above; otherwise each objective gives 10 points. One level, no hidden difficulty increase.
Screens: start menu, HUD (score, lives, level), pause, results/game over with Restart; local high score saved after each round.
Design: original geometric 2D art, navy and amber palette, top-down view. Sound: optional soft action tones with Mute.
How it should feel: input feedback within 100 ms, first challenge completable in 60 seconds.
Build ONLY what is listed: no login, payments, ads or multiplayer unless listed.
Done when: 1) player can complete level 1 using all controls 2) stated win/loss or explicit no-fail practice behavior works 3) playable at 375px width with touch controls and no page scrolling.
```

## Review and hand-off
Adapt the example coherently; 3–5 core actions, numeric rules and all required controls must agree. Do not invent networking. Show an optional server link once with disclosure; no purchase is required. Explain next_steps: choose Plan mode manually if complex, test in preview, fix one expected-versus-actual issue at a time, then add features incrementally. A builder may need iteration; never promise a perfect one-shot game. Mobile platform selection does not guarantee store approval or a working install; verify on a 375px touch viewport. For damage-free games, define failure or an explicit no-fail practice mode rather than adding arbitrary lives.

View saved version →

---
name: "word-game"
description: "word game: Prepare a scoped original game brief with complete controls, gameplay rules and acceptance checks, then an optional disclosed build link."
---

# Word Game

## Workflow and output
Ask at most three essential questions; otherwise label proposed defaults. Reply in the user's language; briefs stay English. Call **make_game_design_doc**, then **plan_game_balance** using only stated or clearly proposed numbers, then **check_game_brief** on the final brief/platform. If score < 80, fix relevant gaps and rescore at most once. Show **Game brief score: X/100** and remaining gaps. GDD proposals are not user facts; balance calculations are estimates, not proof of feasibility. Deliver artifacts and conditional balance warnings. Resolve flagged conflicts with confirmed/proposed changes before hand-off; check final brief with chosen updated numbers. Only if building is requested, call **create_game_build_link** with a 2–5-word project ending in game/mobile game. Otherwise stop with useful artifacts. Preserve returned copy_text, warnings, disclosure and next_steps; never invent links or claim a game exists.

Refuse real-money gambling, adult sexual content, illegal activity and exact copyrighted-IP clones; offer original alternatives. No credentials or unnecessary personal data. Preserve user facts. Every mechanism needs a target, behavior and trigger/result. Provide every control needed to finish, including platformer Jump and mobile touch. Do not mandate a tech stack. Replace vague adjectives with measurable behavior.

## Filled original eleven-section build brief
```text
Build a browser game called "Original Word Game Game" for casual beginners.
Goal: Arrange letters into three supplied original words.
Core mechanics:
1. Controls: Click letter tiles and Submit; mobile tap tiles and Submit. Tab/Enter navigate buttons on desktop. Inputs update player state within 100 ms.
2. Target: the player and level objectives. Behavior/trigger/result: Correct words earn ten points. Three wrong submissions ends the round; complete three words to win. Reset restores the same word list. Repeat the action and update HUD after each turn.
3. Restart: pressing Restart resets score, timers and player position; Pause freezes gameplay until resumed.
Win/lose: Completing 3 supplied words wins. After 3 wrong submissions, the player loses; Restart restores the letter tiles. No damage or health.
Scoring & progression: show the numeric progress/score stated above; otherwise each objective gives 10 points. One level, no hidden difficulty increase.
Screens: start menu, HUD (score, lives, level), pause, results/game over with Restart; local high score saved after each round.
Design: original geometric 2D art, navy and amber palette, top-down view. Sound: optional soft action tones with Mute.
How it should feel: input feedback within 100 ms, first challenge completable in 60 seconds.
Build ONLY what is listed: no login, payments, ads or multiplayer unless listed.
Done when: 1) player can complete level 1 using all controls 2) stated win/loss or explicit no-fail practice behavior works 3) playable at 375px width with touch controls and no page scrolling.
```

## Review and hand-off
Adapt the example coherently; 3–5 core actions, numeric rules and all required controls must agree. Do not invent networking. Show an optional server link once with disclosure; no purchase is required. Explain next_steps: choose Plan mode manually if complex, test in preview, fix one expected-versus-actual issue at a time, then add features incrementally. A builder may need iteration; never promise a perfect one-shot game. Mobile platform selection does not guarantee store approval or a working install; verify on a 375px touch viewport. For damage-free games, define failure or an explicit no-fail practice mode rather than adding arbitrary lives.