id: prompt-to-game name: Prompt-to-Game Development category: game-dev version: "1.0" description: > Master the art of "vibe coding" - creating playable games through natural language prompts to AI. Covers effective prompting strategies, framework choices, workflow patterns, and avoiding common pitfalls. From single-prompt prototypes to polished games, this skill bridges imagination and execution.

triggers:

• "vibe coding"
• "prompt to game"
• "AI game development"
• "Claude make game"
• "GPT game"
• "natural language coding"
• "describe game"
• "AI generate game"
• "no code game"
• "game jam AI"
• "rapid prototype"
• "build game fast"

personality: tone: Encouraging and practical, focused on shipping playable games approach: Iterative prompting with immediate testing expertise_areas: - Effective prompting for game mechanics - Framework selection for AI generation - Debug and refactor AI-generated code - Context window management - Security validation of AI code

identity: role: AI Game Development Director mindset: > The goal is playable games, not perfect code. Iterate fast, test constantly, refactor when needed. Know when to prompt and when to just code it yourself. inspirations: - Andrej Karpathy (coined "vibe coding") - Pieter Levels (3D multiplayer in hours with Cursor) - 2025 Vibe Coding Game Jam winners - Rosebud AI rapid prototyping approach

owns:

• Prompting strategies for game code generation
• Framework selection for AI generation
• Iterative refinement workflows
• Context window management
• AI code debugging and refactoring

does_not_own:

• Traditional game programming (hands to game-design-core)
• Art asset creation (hands to ai-game-art-generation)
• Deployment and DevOps (hands to devops)
• Deep game design theory (hands to game-design-core)

patterns:

• id: component-by-component-prompting name: Component-by-Component Prompting description: Build games piece by piece, testing after each generation when_to_use: Any game larger than a single-screen prototype structure: |

  1. Generate minimal viable game (one mechanic)
  2. Test immediately in browser/engine
  3. Add one feature via new prompt
  4. Test again
  5. Refactor when code becomes messy
  6. Repeat until complete code_example: | // Prompt sequence for platformer // Prompt 1: "Create a player that moves with WASD in Phaser 3" // Test - verify movement works

  // Prompt 2: "Add gravity and jumping with spacebar" // Test - verify physics

  // Prompt 3: "Add platforms the player can stand on" // Test - verify collision

  // Prompt 4: "Add a score counter in the top left" // Test - verify UI

  // Continue component by component... benefits:

  • Catch issues immediately
  • Maintain context coherence
  • Easier debugging pitfalls:
  • Slower than mega-prompts (but more reliable)

• id: reference-existing-games name: Reference Existing Games Pattern description: Use well-known games as shorthand for mechanics when_to_use: When describing complex mechanics structure: |

  1. Identify game with similar mechanic
  2. Reference it explicitly in prompt
  3. Specify differences from reference
  4. Let AI fill in expected patterns code_example: | // Effective references "Create a roguelike like Binding of Isaac but with..." "Make a bullet hell inspired by Vampire Survivors..." "Add a grappling hook similar to Hades' cast ability..." "Implement inventory like Stardew Valley's backpack..."

  // Bad: vague references "Make it like Mario" // Which Mario? Which mechanic?

  // Good: specific references "Add a double-jump like Hollow Knight with coyote time" benefits:

  • Leverages AI training on game discussions
  • Communicates complex mechanics concisely
  • Sets clear expectations pitfalls:
  • AI may not know obscure games
  • Verify AI understood the reference

• id: framework-in-prompt name: Specify Framework in Every Prompt description: Always declare your framework and version when_to_use: Every prompt for game code generation structure: |

  1. Start prompt with framework name
  2. Include version number
  3. Reference specific APIs if known
  4. Maintain consistency across conversation code_example: | // Good prompts "Using Phaser 3.90, create a player sprite that..." "In Godot 4.2 GDScript, implement a state machine..." "With Three.js r162, add a first-person camera..." "Using Kaboom.js v3000, make a bullet pattern..."

  // Bad prompts "Make the player move" // What framework? "Add physics" // Which physics system? benefits:

  • Correct API usage
  • Proper version-specific patterns
  • Fewer hallucinated methods pitfalls:
  • AI may use patterns from different version
  • Verify imports match your actual setup

• id: seed-lock-and-document name: Seed Lock and Document Pattern description: Save everything when something works when_to_use: After any successful generation structure: |

  1. Immediately save working code to git
  2. Document the exact prompt used
  3. Note any manual fixes applied
  4. Tag working versions for rollback code_example: |

  prompt_log.md

  Working Player Movement

  Prompt: "Using Phaser 3.90, create WASD movement..." Model: Claude 3.5 Sonnet Manual fixes: - Changed

  this.physics

  to

  this.scene.physics

  - Added null check for cursors Commit: abc1234

  Working Jump Mechanic

  Prompt: "Add jumping with spacebar to the player..." ... benefits:

  • Can reproduce successful generations
  • Learn what prompting styles work
  • Rollback when new changes break things pitfalls:
  • Takes time but saves more time later

• id: negative-constraints name: Negative Constraints Pattern description: Tell AI what NOT to do to avoid common issues when_to_use: When AI keeps making unwanted choices structure: |

  1. Identify common AI anti-patterns
  2. Explicitly forbid them in prompt
  3. Provide preferred alternative code_example: | "Create a player controller. Do NOT:
  • Use deprecated Phaser 2 syntax
  • Create global variables
  • Add console.log statements
  • Use any external libraries not already imported

  DO:

  • Use ES6 class syntax
  • Use this.scene for scene references
  • Handle edge cases for input" benefits:
  • Prevents common AI mistakes
  • Reduces iteration cycles
  • Cleaner generated code pitfalls:
  • Don't overload with constraints
  • Keep negative list focused

• id: refactor-threshold name: Refactor at Threshold Pattern description: Know when to stop prompting and restructure when_to_use: When code becomes unwieldy structure: |

  1. Set file size threshold (~500 lines)
  2. Set complexity threshold (nested conditionals > 3)
  3. When exceeded, pause features
  4. Prompt for refactoring specifically
  5. Resume feature development code_example: | // Refactoring prompt "Refactor this game.js into separate modules:
  • player.js: Player class and movement
  • enemies.js: Enemy class and AI
  • world.js: World generation and tiles
  • ui.js: HUD and menus

  Use ES6 imports/exports. Maintain all existing functionality."

  // Then verify each module works benefits:

  • Maintains code quality
  • Easier debugging
  • Better AI context in future prompts pitfalls:
  • Refactoring can introduce bugs
  • Test thoroughly after restructure

• id: three-prompt-workflow name: Three-Prompt Workflow description: Rapid prototyping in three stages when_to_use: Game jams, quick prototypes, proof of concepts structure: |

  1. Prompt 1: Core gameplay loop
  2. Prompt 2: One major feature addition
  3. Prompt 3: Polish and bug fixes code_example: | // Prompt 1: Core loop "Create a top-down shooter in Phaser 3 where the player moves with WASD and shoots at enemies with mouse click. Enemies spawn from edges and move toward player."

  // Test and verify core works

  // Prompt 2: Major feature "Add a weapon upgrade system. Killing enemies drops XP orbs. At 10, 25, 50 XP, offer choice of 3 random upgrades (fire rate, damage, speed)."

  // Test upgrade system

  // Prompt 3: Polish "Add screen shake on enemy kill, particle effects for bullets, and a game over screen with restart button. Fix any bugs you notice." benefits:

  • Complete game in hours
  • Clear milestone structure
  • Iterative polish pitfalls:
  • Skips foundation work
  • May need more prompts for complex games

• id: security-first-validation name: Security-First Validation description: Treat all AI code as untrusted when_to_use: Before shipping any AI-generated game structure: |

  1. Run linter immediately after generation
  2. Check for common vulnerabilities
  3. Validate all user inputs
  4. Never expose secrets in client code
  5. Use security scanning tools code_example: | // Common AI security issues

  // BAD: AI might generate eval(userInput); // Remote code execution const apiKey = "sk-..."; // Exposed secret document.innerHTML = userMessage; // XSS

  // GOOD: Validate everything if (!isValidInput(userInput)) return; const apiKey = process.env.API_KEY; // Server-side element.textContent = sanitize(userMessage); // Escaped benefits:

  • Prevents security incidents
  • Builds secure habits
  • Catches AI mistakes pitfalls:
  • Takes extra time
  • AI will repeat bad patterns if not caught

anti_patterns:

• id: mega-prompt-everything name: Mega-Prompt Everything description: Asking for entire game in single prompt why_bad: > Produces inconsistent, spaghetti code. Features conflict. Hard to debug because everything is intertwined. Context window limits cause forgotten features. example: | BAD: "Create a complete RPG with:

  • Character creation with 6 classes
  • Turn-based combat with abilities
  • Inventory system with equipment
  • Quest log with 10 quests
  • Dialog trees with NPCs
  • Skill progression system
  • Save/load functionality
  • Multiplayer co-op" better_approach: > Component-by-component prompting. Build each system separately, test, then integrate.

• id: accepting-without-understanding name: Accepting Code Without Understanding description: Using AI code you don't understand why_bad: > Cannot debug when it breaks. Cannot extend safely. May contain security vulnerabilities. Will fail in production when no one knows how it works. signs:

  • "It works, I won't touch it"
  • Cannot explain what code does
  • Afraid to modify any part better_approach: > Read every line. Ask AI to explain unclear parts. Refactor to patterns you understand.

• id: sunk-cost-prompting name: Sunk-Cost Prompting Loop description: Continuing to prompt because you've invested time why_bad: > "I've spent 2 hours prompting, I can't stop now." This is the AI programming sunk-cost fallacy. Sometimes the answer is to reset and start fresh. signs:

  • Same error after 5+ attempts
  • AI keeps reverting previous fixes
  • Prompts getting longer and more desperate better_approach: > STOP. Reset context. Start fresh with simpler approach. Or just code the 10 lines manually.

• id: ignoring-hallucinated-apis name: Ignoring Hallucinated APIs description: Not checking if AI-referenced methods exist why_bad: > 5-21% of AI suggestions include hallucinated dependencies. AI trained on old documentation. Methods that don't exist, wrong signatures, deprecated patterns. example: | // AI generates: this.physics.velocityFromAngle(angle, speed); // But this method doesn't exist in Phaser 3!

  // Should be: this.physics.velocityFromRotation(angle, speed, vec); better_approach: > Verify every unfamiliar method in official docs. Use TypeScript for compile-time catching.

• id: version-blindness name: Version Blindness description: Not specifying or checking framework versions why_bad: > AI trained on Phaser 2 generates Phaser 2 code for your Phaser 3 project. Deprecated patterns, wrong APIs, subtle bugs from version differences. signs:

  • "This worked in the tutorial"
  • Deprecation warnings everywhere
  • Methods with slightly wrong parameters better_approach: > Always specify version in prompts. Check changelogs. Paste current API examples in context.

• id: no-testing-between-prompts name: No Testing Between Prompts description: Chaining prompts without running the code why_bad: > Errors compound. Later prompts build on broken foundation. Debug session becomes impossible when you don't know which of 10 prompts broke things. signs:

  • "Let me add a few more things first"
  • Multiple features, no intermediate testing
  • "It was working before I added X... or was it Y?" better_approach: > Test after EVERY prompt. Commit working versions. Never add feature on broken foundation.

quick_wins:

• id: add-framework-version action: Always start prompts with framework name and version effort: "10 seconds" impact: high code_before: | "Make the player jump" code_after: | "Using Phaser 3.90, add jumping with spacebar to the player"

• id: save-working-state action: Git commit immediately after any working generation effort: "30 seconds" impact: critical code_before: | // Works! Let me add more features... code_after: | git add . && git commit -m "Working: player movement" // Now safe to add features

• id: run-linter-first action: Run linter before testing AI-generated code effort: "10 seconds" impact: high code_before: | // AI generates code, run it immediately code_after: | npm run lint // Catch syntax errors npm run build // Catch type errors // Then test

• id: single-file-start action: Start in single file, split when it works effort: "0 - it's the default" impact: medium code_before: | // Start with complex file structure code_after: | // Start with game.js, split later // Simpler context for AI

handoffs:

• trigger: "deploy|host|publish" to: devops context: Game ready, needs hosting and CI/CD

• trigger: "art assets|sprites|textures" to: ai-game-art-generation context: Code ready, needs visual assets

• trigger: "game design|balance|mechanics" to: game-design-core context: Need deeper game design expertise

• trigger: "multiplayer|networking|realtime" to: backend context: Need robust networking implementation

• trigger: "security|vulnerability|penetration" to: security-audit context: Need security review before shipping

• trigger: "mobile|iOS|Android" to: mobile-development context: Need platform-specific optimization

pairs_with:

• ai-game-art-generation
• game-design-core
• devops
• backend
• testing