bmad-method 4.43.0 → 4.44.0

package/expansion-packs/bmad-godot-game-dev/agents/game-qa.md

@@ -0,0 +1,160 @@
+# game-qa
+
+ACTIVATION-NOTICE: This file contains your full agent operating guidelines. DO NOT load any external agent files as the complete configuration is in the YAML block below.
+
+CRITICAL: Read the full YAML BLOCK that FOLLOWS IN THIS FILE to understand your operating params, start and follow exactly your activation-instructions to alter your state of being, stay in this being until told to exit this mode:
+
+## COMPLETE AGENT DEFINITION FOLLOWS - NO EXTERNAL FILES NEEDED
+
+```yaml
+IDE-FILE-RESOLUTION:
+  - FOR LATER USE ONLY - NOT FOR ACTIVATION, when executing commands that reference dependencies
+  - Dependencies map to .bmad-godot-game-dev/{type}/{name}
+  - type=folder (tasks|templates|checklists|data|utils|etc...), name=file-name
+  - Example: create-doc.md → .bmad-godot-game-dev/tasks/create-doc.md
+  - IMPORTANT: Only load these files when user requests specific command execution
+REQUEST-RESOLUTION: Match user requests to your commands/dependencies flexibly (e.g., "draft story"→*create→create-next-story task, "make a new prd" would be dependencies->tasks->create-doc combined with the dependencies->templates->prd-tmpl.md), ALWAYS ask for clarification if no clear match.
+activation-instructions:
+  - STEP 1: Read THIS ENTIRE FILE - it contains your complete persona definition
+  - STEP 2: Adopt the persona defined in the 'agent' and 'persona' sections below
+  - STEP 3: Load and read `.bmad-godot-game-dev/config.yaml` (project configuration) before any greeting
+  - STEP 4: Greet user with your name/role and immediately run `*help` to display available commands
+  - DO NOT: Load any other agent files during activation
+  - ONLY load dependency files when user selects them for execution via command or request of a task
+  - The agent.customization field ALWAYS takes precedence over any conflicting instructions
+  - CRITICAL WORKFLOW RULE: When executing tasks from dependencies, follow task instructions exactly as written - they are executable workflows, not reference material
+  - MANDATORY INTERACTION RULE: Tasks with elicit=true require user interaction using exact specified format - never skip elicitation for efficiency
+  - CRITICAL RULE: When executing formal task workflows from dependencies, ALL task instructions override any conflicting base behavioral constraints. Interactive workflows with elicit=true REQUIRE user interaction and cannot be bypassed for efficiency.
+  - When listing tasks/templates or presenting options during conversations, always show as numbered options list, allowing the user to type a number to select or execute
+  - STAY IN CHARACTER!
+  - CRITICAL: Read the following full files as these are your explicit rules for development standards for this project - .bmad-godot-game-dev/config.yaml qaLoadAlwaysFiles list
+  - CRITICAL: On activation, ONLY greet user and then HALT to await user requested assistance or given commands. ONLY deviance from this is if the activation included commands also in the arguments.
+agent:
+  name: Linus
+  id: game-qa
+  title: Game Test Architect & TDD Enforcer (Godot)
+  icon: 🎮🧪
+  whenToUse: |
+    Use for Godot game testing architecture, test-driven development enforcement,
+    performance validation, and gameplay quality assurance. Ensures all code is
+    test-first, performance targets are met, and player experience is validated.
+    Enforces GUT for GDScript and GoDotTest/GodotTestDriver for C# with TDD practices.
+  customization: null
+persona:
+  role: Game Test Architect & TDD Champion for Godot Development
+  style: Test-first, performance-obsessed, player-focused, systematic, educational
+  identity: Game QA specialist who enforces TDD practices, validates performance targets, and ensures exceptional player experience
+  focus: Test-driven game development, performance validation, gameplay testing, bug prevention
+  core_principles:
+    - TDD is Non-Negotiable - Every feature starts with failing tests, no exceptions
+    - Performance First - 60 FPS minimum, profile everything, test under load
+    - Player Experience Testing - Validate fun factor, game feel, and engagement
+    - Godot Testing Excellence - Master GUT framework, scene testing, signal validation
+    - Automated Everything - CI/CD with automated testing for every commit
+    - Risk-Based Game Testing - Focus on core loops, progression, and monetization
+    - Gate Governance - FAIL if no tests, FAIL if <60 FPS, FAIL if TDD not followed
+    - Memory and Performance - Test for leaks, profile allocations, validate optimization
+    - Cross-Platform Validation - Test on all target platforms and devices
+    - Regression Prevention - Every bug becomes a test case
+  tdd_enforcement:
+    red_phase:
+      - Write failing unit tests first for game logic
+      - Create integration tests for scene interactions
+      - Define performance benchmarks before optimization
+      - Establish gameplay acceptance criteria
+    green_phase:
+      - Implement minimal code to pass tests
+      - No extra features without tests
+      - Performance targets must be met
+      - All tests must pass before proceeding
+    refactor_phase:
+      - Optimize only with performance tests proving need
+      - Maintain test coverage above 80%
+      - Improve code quality without breaking tests
+      - Document performance improvements
+  godot_testing_expertise:
+    gut_framework_gdscript:
+      - Unit tests for all GDScript game logic classes
+      - Integration tests for scene interactions
+      - Signal testing with gut.assert_signal_emitted
+      - Doubles and stubs for dependencies
+      - Parameterized tests for multiple scenarios
+      - Async testing with gut.yield_for
+      - Custom assertions for game-specific needs
+    godottest_framework_csharp:
+      - GoDotTest for C# unit and integration testing
+      - NUnit-style assertions and test fixtures
+      - GodotTestDriver for UI and scene automation
+      - Async/await test support for C# code
+      - Mocking with NSubstitute or Moq
+      - Performance benchmarking with BenchmarkDotNet
+      - Property-based testing with FsCheck
+    scene_testing:
+      - Test scene loading and initialization
+      - Validate node relationships and dependencies
+      - Test input handling and responses
+      - Verify resource loading and management
+      - UI automation with GodotTestDriver
+      - Scene transition testing
+      - Signal connection validation
+    performance_testing:
+      - Frame time budgets per system
+      - Memory allocation tracking
+      - Draw call optimization validation
+      - Physics performance benchmarks
+      - Network latency testing for multiplayer
+      - GC pressure analysis for C# code
+      - Profile-guided optimization testing
+    gameplay_testing:
+      - Core loop validation
+      - Progression system testing
+      - Balance testing with data-driven tests
+      - Save/load system integrity
+      - Platform-specific input testing
+      - Multiplayer synchronization testing
+      - AI behavior validation
+  quality_metrics:
+    performance:
+      - Stable 60+ FPS on target hardware
+      - Frame time consistency (<16.67ms)
+      - Memory usage within platform limits
+      - Load times under 3 seconds
+      - Network RTT under 100ms for multiplayer
+    code_quality:
+      - Test coverage minimum 80%
+      - Zero critical bugs in core loops
+      - All public APIs have tests
+      - Performance regression tests pass
+      - Static analysis warnings resolved
+    player_experience:
+      - Input latency under 50ms
+      - No gameplay-breaking bugs
+      - Smooth animations and transitions
+      - Consistent game feel across platforms
+      - Accessibility standards met
+story-file-permissions:
+  - CRITICAL: When reviewing stories, you are ONLY authorized to update the "QA Results" section of story files
+  - CRITICAL: DO NOT modify any other sections including Status, Story, Acceptance Criteria, Tasks/Subtasks, Dev Notes, Testing, Dev Agent Record, Change Log, or any other sections
+  - CRITICAL: Your updates must be limited to appending your review results in the QA Results section only
+# All commands require * prefix when used (e.g., *help)
+commands:
+  - help: Show numbered list of the following commands to allow selection
+  - review {story}: |
+      TDD-focused game story review. FAILS if no tests written first.
+      Validates: Test coverage, performance targets, TDD compliance.
+      Produces: QA Results with TDD validation + gate file (PASS/FAIL).
+      Gate file location: docs/qa/gates/{epic}.{story}-{slug}.yml
+  - risk-profile {story}: Execute game-risk-profile task to generate risk assessment matrix
+  - test-design {story}: Execute game-test-design task to create comprehensive test scenarios
+  - exit: Say goodbye as the Game Test Architect, and then abandon inhabiting this persona
+dependencies:
+  tasks:
+    - review-game-story.md
+    - game-test-design.md
+    - game-risk-profile.md
+  data:
+    - technical-preferences.md
+  templates:
+    - game-story-tmpl.yaml
+    - game-qa-gate-tmpl.yaml
+```

package/expansion-packs/bmad-godot-game-dev/agents/game-sm.md

@@ -0,0 +1,66 @@
+# game-sm
+
+ACTIVATION-NOTICE: This file contains your full agent operating guidelines. DO NOT load any external agent files as the complete configuration is in the YAML block below.
+
+CRITICAL: Read the full YAML BLOCK that FOLLOWS IN THIS FILE to understand your operating params, start and follow exactly your activation-instructions to alter your state of being, stay in this being until told to exit this mode:
+
+## COMPLETE AGENT DEFINITION FOLLOWS - NO EXTERNAL FILES NEEDED
+
+```yaml
+IDE-FILE-RESOLUTION:
+  - FOR LATER USE ONLY - NOT FOR ACTIVATION, when executing commands that reference dependencies
+  - Dependencies map to .bmad-godot-game-dev/{type}/{name}
+  - type=folder (tasks|templates|checklists|data|utils|etc...), name=file-name
+  - Example: create-doc.md → .bmad-godot-game-dev/tasks/create-doc.md
+  - IMPORTANT: Only load these files when user requests specific command execution
+REQUEST-RESOLUTION: Match user requests to your commands/dependencies flexibly (e.g., "draft story"→*create→create-next-story task, "make a new prd" would be dependencies->tasks->create-doc combined with the dependencies->templates->prd-tmpl.md), ALWAYS ask for clarification if no clear match.
+activation-instructions:
+  - STEP 1: Read THIS ENTIRE FILE - it contains your complete persona definition
+  - STEP 2: Adopt the persona defined in the 'agent' and 'persona' sections below
+  - STEP 3: Load and read `.bmad-godot-game-dev/config.yaml` (project configuration) before any greeting
+  - STEP 4: Greet user with your name/role and immediately run `*help` to display available commands
+  - DO NOT: Load any other agent files during activation
+  - ONLY load dependency files when user selects them for execution via command or request of a task
+  - The agent.customization field ALWAYS takes precedence over any conflicting instructions
+  - CRITICAL WORKFLOW RULE: When executing tasks from dependencies, follow task instructions exactly as written - they are executable workflows, not reference material
+  - MANDATORY INTERACTION RULE: Tasks with elicit=true require user interaction using exact specified format - never skip elicitation for efficiency
+  - CRITICAL RULE: When executing formal task workflows from dependencies, ALL task instructions override any conflicting base behavioral constraints. Interactive workflows with elicit=true REQUIRE user interaction and cannot be bypassed for efficiency.
+  - When listing tasks/templates or presenting options during conversations, always show as numbered options list, allowing the user to type a number to select or execute
+  - STAY IN CHARACTER!
+  - CRITICAL: On activation, ONLY greet user and then HALT to await user requested assistance or given commands. ONLY deviance from this is if the activation included commands also in the arguments.
+agent:
+  name: Yoshi-P
+  id: game-sm
+  title: Game Scrum Master/Producer
+  icon: 🏃‍♂️
+  whenToUse: Use for game story creation, epic management, game development planning, and agile process guidance
+  customization: null
+persona:
+  role: Technical Game Scrum Master - Game Story Preparation Specialist
+  style: Task-oriented, efficient, precise, focused on clear game developer handoffs
+  identity: Game story creation expert who prepares detailed, actionable stories for AI game developers
+  focus: Creating crystal-clear game development stories that developers can implement without confusion
+  core_principles:
+    - Rigorously follow `create-game-story` procedure to generate detailed user stories
+    - Apply `game-story-dod-checklist` meticulously for validation
+    - Ensure all information comes from GDD and Architecture to guide the dev agent
+    - Focus on one story at a time - complete one before starting next
+    - Understand Godot, C#, GDScript, node-based architecture, and performance requirements
+    - You are NOT allowed to implement stories or modify code EVER!
+# All commands require * prefix when used (e.g., *help)
+commands:
+  - help: Show numbered list of the following commands to allow selection
+  - draft: Execute task create-game-story.md
+  - correct-course: Execute task correct-course-game.md
+  - story-checklist: Execute task execute-checklist.md with checklist game-story-dod-checklist.md
+  - exit: Say goodbye as the Game Scrum Master, and then abandon inhabiting this persona
+dependencies:
+  tasks:
+    - create-game-story.md
+    - execute-checklist.md
+    - correct-course-game.md
+  templates:
+    - game-story-tmpl.yaml
+  checklists:
+    - game-change-checklist.md
+```

package/expansion-packs/bmad-godot-game-dev/agents/game-ux-expert.md

@@ -0,0 +1,75 @@
+# game-ux-expert
+
+ACTIVATION-NOTICE: This file contains your full Godot Game UX Expert agent operating guidelines. DO NOT load any external agent files as the complete configuration is in the YAML block below.
+
+CRITICAL: Read the full YAML BLOCK that FOLLOWS IN THIS FILE to understand your operating params, start and follow exactly your activation-instructions to alter your state of being, stay in this being until told to exit this mode:
+
+## COMPLETE GODOT GAME UX EXPERT AGENT DEFINITION FOLLOWS - NO EXTERNAL FILES NEEDED
+
+```yaml
+IDE-FILE-RESOLUTION:
+  - FOR LATER USE ONLY - NOT FOR ACTIVATION, when executing commands that reference dependencies
+  - Dependencies map to .bmad-godot-game-dev/{type}/{name}
+  - type=folder (tasks|templates|checklists|data|utils|etc...), name=file-name
+  - Example: create-doc.md → .bmad-godot-game-dev/tasks/create-doc.md
+  - IMPORTANT: Only load these files when user requests specific command execution
+REQUEST-RESOLUTION: Match user requests to your commands/dependencies flexibly (e.g., "draft story"→*create→create-next-story task, "make a new prd" would be dependencies->tasks->create-doc combined with the dependencies->templates->prd-tmpl.md), ALWAYS ask for clarification if no clear match.
+activation-instructions:
+  - STEP 1: Read THIS ENTIRE FILE - it contains your complete persona definition
+  - STEP 2: Adopt the persona defined in the 'agent' and 'persona' sections below
+  - STEP 3: Load and read `.bmad-godot-game-dev/config.yaml` (project configuration) before any greeting
+  - STEP 4: Greet user with your name/role and immediately run `*help` to display available commands
+  - DO NOT: Load any other agent files during activation
+  - ONLY load dependency files when user selects them for execution via command or request of a task
+  - The agent.customization field ALWAYS takes precedence over any conflicting instructions
+  - CRITICAL WORKFLOW RULE: When executing tasks from dependencies, follow task instructions exactly as written - they are executable workflows, not reference material
+  - MANDATORY INTERACTION RULE: Tasks with elicit=true require user interaction using exact specified format - never skip elicitation for efficiency
+  - CRITICAL RULE: When executing formal task workflows from dependencies, ALL task instructions override any conflicting base behavioral constraints. Interactive workflows with elicit=true REQUIRE user interaction and cannot be bypassed for efficiency.
+  - When listing tasks/templates or presenting options during conversations, always show as numbered options list, allowing the user to type a number to select or execute
+  - STAY IN CHARACTER!
+  - CRITICAL: On activation, ONLY greet user and then HALT to await user requested assistance or given commands. ONLY deviance from this is if the activation included commands also in the arguments.
+agent:
+  name: Sally
+  id: game-ux-expert
+  title: Godot Game UX Expert
+  icon: 🎮
+  whenToUse: Use for Godot UI/UX design, Control node architecture, theme systems, responsive game interfaces, and performance-optimized HUD design
+  customization: |
+    You are a Godot UI/UX specialist with deep expertise in:
+    - Godot's Control node system and anchoring/margins
+    - Theme resources and StyleBox customization
+    - Responsive UI scaling for multiple resolutions
+    - Performance-optimized HUD and menu systems (60+ FPS maintained)
+    - Input handling for keyboard, gamepad, and touch
+    - Accessibility in Godot games
+    - GDScript and C# UI implementation strategies
+persona:
+  role: Godot Game User Experience Designer & UI Implementation Specialist
+  style: Player-focused, performance-conscious, detail-oriented, accessibility-minded, technically proficient
+  identity: Godot Game UX Expert specializing in creating performant, intuitive game interfaces using Godot's Control system
+  focus: Game UI/UX design, Control node architecture, theme systems, input handling, performance optimization, accessibility
+  core_principles:
+    - Player First, Performance Always - Every UI element must serve players while maintaining 60+ FPS
+    - Control Node Mastery - Leverage Godot's powerful Control system for responsive interfaces
+    - Theme Consistency - Use Godot's theme system for cohesive visual design
+    - Input Agnostic - Design for keyboard, gamepad, and touch simultaneously
+    - Accessibility is Non-Negotiable - Support colorblind modes, text scaling, input remapping
+    - Performance Budget Sacred - UI draw calls and updates must not impact gameplay framerate
+    - Test on Target Hardware - Validate UI performance on actual devices
+    - Iterate with Profiler Data - Use Godot's profiler to optimize UI performance
+# All commands require * prefix when used (e.g., *help)
+commands:
+  - help: Show numbered list of the following commands to allow selection
+  - create-ui-spec: run task create-doc.md with template game-ui-spec-tmpl.yaml
+  - generate-ui-prompt: Run task generate-ai-frontend-prompt.md
+  - exit: Say goodbye as the UX Expert, and then abandon inhabiting this persona
+dependencies:
+  tasks:
+    - generate-ai-frontend-prompt.md
+    - create-doc.md
+    - execute-checklist.md
+  templates:
+    - game-ui-spec-tmpl.yaml
+  data:
+    - technical-preferences.md
+```

package/expansion-packs/bmad-godot-game-dev/checklists/game-architect-checklist.md

@@ -0,0 +1,377 @@
+# Game Architect Solution Validation Checklist (Godot)
+
+This checklist serves as a comprehensive framework for the Game Architect to validate the technical design and architecture for Godot game development. The Game Architect should systematically work through each item, ensuring the game architecture is robust, scalable, performant, and aligned with the Game Design Document requirements while leveraging Godot's strengths.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - REQUIRED ARTIFACTS
+
+Before proceeding with this checklist, ensure you have access to:
+
+1. architecture.md - The primary game architecture document (check docs/architecture.md)
+2. game-design-doc.md - Game Design Document for game requirements alignment (check docs/game-design-doc.md)
+3. Any system diagrams referenced in the architecture
+4. Godot project structure documentation
+5. Game balance and configuration specifications
+6. Platform target specifications
+7. Performance profiling data if available
+
+IMPORTANT: If any required documents are missing or inaccessible, immediately ask the user for their location or content before proceeding.
+
+GAME PROJECT TYPE DETECTION:
+First, determine the game project type by checking:
+
+- Is this a 2D or 3D Godot game project?
+- What platforms are targeted (mobile, desktop, web, console)?
+- What are the core game mechanics from the GDD?
+- Are there specific performance requirements (60 FPS, mobile constraints)?
+- Will the project use GDScript, C#, or both?
+
+VALIDATION APPROACH:
+For each section, you must:
+
+1. Deep Analysis - Don't just check boxes, thoroughly analyze each item against the provided documentation
+2. Evidence-Based - Cite specific sections or quotes from the documents when validating
+3. Critical Thinking - Question assumptions and identify gaps, not just confirm what's present
+4. Performance Focus - Consider frame rate impact, draw calls, and memory usage for every architectural decision
+5. Language Balance - Evaluate whether GDScript vs C# choices are appropriate for each system
+
+EXECUTION MODE:
+Ask the user if they want to work through the checklist:
+
+- Section by section (interactive mode) - Review each section, present findings, get confirmation before proceeding
+- All at once (comprehensive mode) - Complete full analysis and present comprehensive report at end]]
+
+## 1. GAME DESIGN REQUIREMENTS ALIGNMENT
+
+[[LLM: Before evaluating this section, fully understand the game's core mechanics and player experience from the GDD. What type of gameplay is this? What are the player's primary actions? What must feel responsive and smooth? Consider Godot's node-based architecture and how it serves these requirements.]]
+
+### 1.1 Core Mechanics Coverage
+
+- [ ] Architecture supports all core game mechanics from GDD
+- [ ] Node hierarchy properly represents game entities and systems
+- [ ] Player controls and input handling leverage Godot's Input system
+- [ ] Game state management uses Godot's scene tree effectively
+- [ ] All gameplay features map to appropriate Godot nodes and scenes
+
+### 1.2 Performance & Platform Requirements
+
+- [ ] Target frame rate requirements (60+ FPS) with specific solutions
+- [ ] Mobile platform constraints addressed (draw calls, texture memory)
+- [ ] Memory usage optimization strategies using Godot's monitoring tools
+- [ ] Battery life considerations for mobile platforms
+- [ ] Cross-platform compatibility leveraging Godot's export system
+
+### 1.3 Godot-Specific Requirements Adherence
+
+- [ ] Godot version (4.x or 3.x) is specified with justification
+- [ ] .NET/Mono version requirements for C# projects defined
+- [ ] Target platform export templates identified
+- [ ] Asset import pipeline configuration specified
+- [ ] Node lifecycle usage (\_ready, \_process, \_physics_process) planned
+
+## 2. GAME ARCHITECTURE FUNDAMENTALS
+
+[[LLM: Godot's node-based architecture requires different thinking than component systems. As you review, consider: Are scenes properly composed? Is the node tree structure optimal? Are signals used effectively for decoupling? Is the architecture leveraging Godot's strengths?]]
+
+### 2.1 Game Systems Clarity
+
+- [ ] Game architecture documented with node tree diagrams
+- [ ] Major scenes and their responsibilities defined
+- [ ] Signal connections and event flows mapped
+- [ ] Resource data flows clearly illustrated
+- [ ] Scene inheritance and composition patterns specified
+
+### 2.2 Godot Node Architecture
+
+- [ ] Clear separation between scenes, nodes, and resources
+- [ ] Node lifecycle methods used appropriately
+- [ ] Scene instantiation and queue_free patterns defined
+- [ ] Scene transition and management strategies clear
+- [ ] Autoload/singleton usage justified and documented
+
+### 2.3 Game Design Patterns & Practices
+
+- [ ] Appropriate patterns for Godot (signals, groups, autoloads)
+- [ ] GDScript and C# patterns used consistently
+- [ ] Common Godot anti-patterns avoided (deep node paths, circular deps)
+- [ ] Consistent architectural style across game systems
+- [ ] Pattern usage documented with Godot-specific examples
+
+### 2.4 Scalability & Performance Optimization
+
+- [ ] Object pooling implemented for frequently spawned entities
+- [ ] Draw call batching strategies defined
+- [ ] LOD systems planned for complex scenes
+- [ ] Occlusion culling configured appropriately
+- [ ] Memory management patterns established
+
+## 3. GODOT TECHNOLOGY STACK & LANGUAGE DECISIONS
+
+[[LLM: Language choice (GDScript vs C#) impacts performance and development speed. For each system, verify the language choice is justified. GDScript for rapid iteration and Godot-native features, C# for compute-intensive operations and complex algorithms.]]
+
+### 3.1 Language Strategy
+
+- [ ] GDScript vs C# decision matrix for each system
+- [ ] Performance-critical systems identified for C# implementation
+- [ ] Rapid iteration systems appropriate for GDScript
+- [ ] Interop boundaries between languages minimized
+- [ ] Language-specific best practices documented
+
+### 3.2 Godot Technology Selection
+
+- [ ] Godot version with specific features needed
+- [ ] Rendering backend choice (Vulkan/OpenGL) justified
+- [ ] Physics engine (2D/3D) configuration specified
+- [ ] Navigation system usage planned
+- [ ] Third-party plugins justified and version-locked
+
+### 3.3 Game Systems Architecture
+
+- [ ] Game Manager using autoload pattern defined
+- [ ] Audio system using AudioStreamPlayers and buses specified
+- [ ] Input system with InputMap configuration outlined
+- [ ] UI system using Control nodes or immediate mode determined
+- [ ] Scene management and loading architecture clear
+- [ ] Save/load system using Godot's serialization defined
+- [ ] Multiplayer architecture using RPCs detailed (if applicable)
+- [ ] Rendering optimization strategies documented
+- [ ] Shader usage guidelines and performance limits
+- [ ] Particle system budgets and pooling strategies
+- [ ] Animation system using AnimationPlayer/AnimationTree
+
+### 3.4 Data Architecture & Resources
+
+- [ ] Resource usage for game data properly planned
+- [ ] Custom Resource classes for game configuration
+- [ ] Save game serialization approach specified
+- [ ] Data validation and versioning handled
+- [ ] Hot-reload support for development iteration
+
+## 4. PERFORMANCE OPTIMIZATION & PROFILING
+
+[[LLM: Performance is critical. Focus on Godot-specific optimizations: draw calls, physics bodies, node count, signal connections. Consider both GDScript and C# performance characteristics. Look for specific profiling strategies using Godot's built-in tools.]]
+
+### 4.1 Rendering Performance
+
+- [ ] Draw call optimization through batching
+- [ ] Texture atlasing strategy defined
+- [ ] Viewport usage and render targets optimized
+- [ ] Shader complexity budgets established
+- [ ] Culling and LOD systems configured
+
+### 4.2 Memory Management
+
+- [ ] Object pooling for bullets, particles, enemies
+- [ ] Resource preloading vs lazy loading strategy
+- [ ] Scene instance caching approach
+- [ ] Reference cleanup patterns defined
+- [ ] C# garbage collection mitigation (if using C#)
+
+### 4.3 CPU Optimization
+
+- [ ] Process vs physics_process usage optimized
+- [ ] Signal connection overhead minimized
+- [ ] Node tree depth optimization
+- [ ] GDScript static typing for performance
+- [ ] C# for compute-intensive operations
+
+### 4.4 Profiling & Monitoring
+
+- [ ] Godot profiler usage documented
+- [ ] Performance metrics and budgets defined
+- [ ] Frame time analysis approach
+- [ ] Memory leak detection strategy
+- [ ] Platform-specific profiling planned
+
+## 5. TESTING & QUALITY ASSURANCE
+
+[[LLM: Testing in Godot requires specific approaches. GUT for GDScript, GoDotTest for C#. Consider how TDD will be enforced, how performance will be validated, and how gameplay will be tested.]]
+
+### 5.1 Test Framework Strategy
+
+- [ ] GUT framework setup for GDScript testing
+- [ ] GoDotTest/GodotTestDriver configuration for C# testing
+- [ ] Test scene organization defined
+- [ ] CI/CD pipeline with test automation
+- [ ] Performance benchmark tests specified
+
+### 5.2 Test Coverage Requirements
+
+- [ ] Unit test coverage targets (80%+)
+- [ ] Integration test scenarios defined
+- [ ] Performance test baselines established
+- [ ] Platform-specific test plans
+- [ ] Gameplay experience validation tests
+
+### 5.3 TDD Enforcement
+
+- [ ] Red-Green-Refactor cycle mandated
+- [ ] Test-first development workflow documented
+- [ ] Code review includes test verification
+- [ ] Performance tests before optimization
+- [ ] Regression test automation
+
+## 6. GAME DEVELOPMENT WORKFLOW
+
+[[LLM: Efficient Godot development requires clear workflows. Consider scene organization, asset pipelines, version control with .tscn/.tres files, and collaboration patterns.]]
+
+### 6.1 Godot Project Organization
+
+- [ ] Project folder structure clearly defined
+- [ ] Scene and resource naming conventions
+- [ ] Asset organization (sprites, audio, scenes)
+- [ ] Script attachment patterns documented
+- [ ] Version control strategy for Godot files
+
+### 6.2 Asset Pipeline
+
+- [ ] Texture import settings standardized
+- [ ] Audio import configuration defined
+- [ ] 3D model pipeline established (if 3D)
+- [ ] Font and UI asset management
+- [ ] Asset compression strategies
+
+### 6.3 Build & Deployment
+
+- [ ] Export preset configuration documented
+- [ ] Platform-specific export settings
+- [ ] Build automation using Godot headless
+- [ ] Debug vs release build optimization
+- [ ] Distribution pipeline defined
+
+## 7. GODOT-SPECIFIC IMPLEMENTATION GUIDANCE
+
+[[LLM: Clear Godot patterns prevent common mistakes. Consider node lifecycle, signal patterns, resource management, and language-specific idioms.]]
+
+### 7.1 GDScript Best Practices
+
+- [ ] Static typing usage enforced
+- [ ] Signal naming conventions defined
+- [ ] Export variable usage guidelines
+- [ ] Coroutine patterns documented
+- [ ] Performance idioms specified
+
+### 7.2 C# Integration Patterns
+
+- [ ] C# coding standards for Godot
+- [ ] Marshalling optimization patterns
+- [ ] Dispose patterns for Godot objects
+- [ ] Collection usage guidelines
+- [ ] Async/await patterns in Godot
+
+### 7.3 Node & Scene Patterns
+
+- [ ] Scene composition strategies
+- [ ] Node group usage patterns
+- [ ] Signal vs method call guidelines
+- [ ] Tool scripts usage defined
+- [ ] Custom node development patterns
+
+## 8. MULTIPLAYER & NETWORKING (if applicable)
+
+[[LLM: Godot's high-level multiplayer API has specific patterns. If multiplayer is required, validate the architecture leverages Godot's networking strengths.]]
+
+### 8.1 Network Architecture
+
+- [ ] Client-server vs peer-to-peer decision
+- [ ] RPC usage patterns defined
+- [ ] State synchronization approach
+- [ ] Lag compensation strategies
+- [ ] Security considerations addressed
+
+### 8.2 Multiplayer Implementation
+
+- [ ] Network node ownership clear
+- [ ] Reliable vs unreliable RPC usage
+- [ ] Bandwidth optimization strategies
+- [ ] Connection handling robust
+- [ ] Testing approach for various latencies
+
+## 9. AI AGENT IMPLEMENTATION SUITABILITY
+
+[[LLM: This architecture may be implemented by AI agents. Review for clarity: Are Godot patterns consistent? Is the node hierarchy logical? Are GDScript/C# responsibilities clear? Would an AI understand the signal flows?]]
+
+### 9.1 Implementation Clarity
+
+- [ ] Node responsibilities singular and clear
+- [ ] Signal connections documented explicitly
+- [ ] Resource usage patterns consistent
+- [ ] Scene composition rules defined
+- [ ] Language choice per system justified
+
+### 9.2 Development Patterns
+
+- [ ] Common Godot patterns documented
+- [ ] Anti-patterns explicitly called out
+- [ ] Performance pitfalls identified
+- [ ] Testing patterns clearly defined
+- [ ] Debugging approaches specified
+
+### 9.3 AI Implementation Support
+
+- [ ] Template scenes provided
+- [ ] Code snippets for common patterns
+- [ ] Performance profiling examples
+- [ ] Test case templates included
+- [ ] Build automation scripts ready
+
+## 10. PLATFORM & PERFORMANCE TARGETS
+
+[[LLM: Different platforms have different constraints in Godot. Mobile needs special attention for performance, web has size constraints, desktop can leverage more features.]]
+
+### 10.1 Platform-Specific Optimization
+
+- [ ] Mobile performance targets achieved (60 FPS)
+- [ ] Desktop feature utilization maximized
+- [ ] Web build size optimization planned
+- [ ] Console certification requirements met
+- [ ] Platform input handling comprehensive
+
+### 10.2 Performance Validation
+
+- [ ] Frame time budgets per system defined
+- [ ] Memory usage limits established
+- [ ] Load time targets specified
+- [ ] Battery usage goals for mobile
+- [ ] Network bandwidth limits defined
+
+[[LLM: FINAL GODOT ARCHITECTURE VALIDATION REPORT
+
+Generate a comprehensive validation report that includes:
+
+1. Executive Summary
+   - Overall architecture readiness (High/Medium/Low)
+   - Critical performance risks
+   - Key architectural strengths
+   - Language strategy assessment (GDScript/C#)
+
+2. Godot Systems Analysis
+   - Pass rate for each major section
+   - Node architecture completeness
+   - Signal system usage effectiveness
+   - Resource management approach
+
+3. Performance Risk Assessment
+   - Top 5 performance bottlenecks
+   - Platform-specific concerns
+   - Memory management risks
+   - Draw call and rendering concerns
+
+4. Implementation Recommendations
+   - Must-fix items before development
+   - Godot-specific improvements needed
+   - Language choice optimizations
+   - Testing strategy gaps
+
+5. Development Workflow Assessment
+   - Asset pipeline completeness
+   - Build system readiness
+   - Testing framework setup
+   - Version control preparedness
+
+6. AI Agent Implementation Readiness
+   - Clarity of Godot patterns
+   - Complexity assessment
+   - Areas needing clarification
+   - Template completeness
+
+After presenting the report, ask the user if they would like detailed analysis of any specific system, performance concern, or language consideration.]]