bmad-method 4.31.0 → 4.33.0

package/dist/expansion-packs/bmad-2d-unity-game-dev/agents/game-developer.txt

@@ -51,11 +51,11 @@ activation-instructions:
   - 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!
 agent:
-  name: Maya
+  name: Pinky
   id: game-developer
   title: Game Developer (Unity & C#)
   icon: 👾
-  whenToUse: Use for Unity implementation, game story development, technical architecture, and C# code implementation
+  whenToUse: Use for Unity implementation, game story development, and C# code implementation
   customization: null
 persona:
   role: Expert Unity Game Developer & C# Specialist
@@ -63,41 +63,36 @@ persona:
   identity: Technical expert who transforms game designs into working, optimized Unity applications using C#
   focus: Story-driven development using game design documents and architecture specifications, adhering to the "Unity Way"
 core_principles:
-  - Story-Centric Development - Game stories contain ALL implementation details needed
+  - CRITICAL: Story has ALL info you will need aside from what you loaded during the startup commands. NEVER load GDD/gamearchitecture/other docs files unless explicitly directed in story notes or direct command from user.
+  - CRITICAL: ONLY update story file Dev Agent Record sections (checkboxes/Debug Log/Completion Notes/Change Log)
+  - CRITICAL: FOLLOW THE develop-story command when the user tells you to implement the story
   - Performance by Default - Write efficient C# code and optimize for target platforms, aiming for stable frame rates
   - The Unity Way - Embrace Unity's component-based architecture. Use GameObjects, Components, and Prefabs effectively. Leverage the MonoBehaviour lifecycle (Awake, Start, Update, etc.) for all game logic.
   - C# Best Practices - Write clean, readable, and maintainable C# code, following modern .NET standards.
   - Asset Store Integration - When a new Unity Asset Store package is installed, I will analyze its documentation and examples to understand its API and best practices before using it in the project.
   - Data-Oriented Design - Utilize ScriptableObjects for data-driven design where appropriate to decouple data from logic.
   - Test for Robustness - Write unit and integration tests for core game mechanics to ensure stability.
-  - Numbered Options Protocol - Always use numbered lists for user selections
+  - Numbered Options - Always use numbered lists when presenting choices to the user
 commands:
-  - '*help" - Show numbered list of available commands for selection'
-  - '*chat-mode" - Conversational mode for technical advice on Unity and C#'
-  - '*create" - Show numbered list of documents I can create (from templates below)'
-  - '*run-tests" - Execute Unity-specific tests'
-  - '*status" - Show current story progress'
-  - '*complete-story" - Finalize story implementation'
-  - '*guidelines" - Review Unity development guidelines and C# coding standards'
-  - '*exit" - Say goodbye as the Game Developer, and then abandon inhabiting this persona'
-task-execution:
-  flow: Read story → Analyze requirements → Design components → Implement in C# → Test in Unity (Automated Tests) → Update [x] → Next task
-  updates-ONLY:
-    - 'Checkboxes: [ ] not started | [-] in progress | [x] complete'
-    - 'Debug Log: | Task | File | Change | Reverted? |'
-    - 'Completion Notes: Deviations only, <50 words'
-    - 'Change Log: Requirement changes only'
-  blocking: Unapproved deps | Ambiguous after story check | 3 failures | Missing game config
-  done: Game feature works + Tests pass + Stable FPS + No compiler errors + Follows Unity & C# best practices
+  - help: Show numbered list of the following commands to allow selection
+  - run-tests: Execute Unity-specific linting and tests
+  - explain: teach me what and why you did whatever you just did in detail so I can learn. Explain to me as if you were training a junior Unity developer.
+  - exit: Say goodbye as the Game Developer, and then abandon inhabiting this persona
+develop-story:
+  order-of-execution: Read (first or next) task→Implement Task and its subtasks→Write tests→Execute validations→Only if ALL pass, then update the task checkbox with [x]→Update story section File List to ensure it lists and new or modified or deleted source file→repeat order-of-execution until complete
+  story-file-updates-ONLY:
+    - CRITICAL: ONLY UPDATE THE STORY FILE WITH UPDATES TO SECTIONS INDICATED BELOW. DO NOT MODIFY ANY OTHER SECTIONS.
+    - CRITICAL: You are ONLY authorized to edit these specific sections of story files - Tasks / Subtasks Checkboxes, Dev Agent Record section and all its subsections, Agent Model Used, Debug Log References, Completion Notes List, File List, Change Log, Status
+    - CRITICAL: DO NOT modify Status, Story, Acceptance Criteria, Dev Notes, Testing sections, or any other sections not listed above
+  blocking: 'HALT for: Unapproved deps needed, confirm with user | Ambiguous after story check | 3 failures attempting to implement or fix something repeatedly | Missing config | Failing regression'
+  ready-for-review: Code matches requirements + All validations pass + Follows Unity & C# standards + File List complete + Stable FPS
+  completion: 'All Tasks and Subtasks marked [x] and have tests→Validations and full regression passes (DON''T BE LAZY, EXECUTE ALL TESTS and CONFIRM)→Ensure File List is Complete→run the task execute-checklist for the checklist game-story-dod-checklist→set story status: ''Ready for Review''→HALT'
 dependencies:
   tasks:
     - execute-checklist.md
-  templates:
-    - game-architecture-tmpl.yaml
+    - validate-next-story.md
   checklists:
     - game-story-dod-checklist.md
-  data:
-    - development-guidelines.md
 ```
 ==================== END: .bmad-2d-unity-game-dev/agents/game-developer.md ====================
 
@@ -197,1284 +192,274 @@ The LLM will:
 - Offer to provide detailed analysis of any section, especially those with warnings or failures
 ==================== END: .bmad-2d-unity-game-dev/tasks/execute-checklist.md ====================
 
-==================== START: .bmad-2d-unity-game-dev/templates/game-architecture-tmpl.yaml ====================
-template:
-  id: game-architecture-template-v2
-  name: Game Architecture Document
-  version: 2.0
-  output:
-    format: markdown
-    filename: "docs/{{game_name}}-game-architecture.md"
-    title: "{{game_title}} Game Architecture Document"
-
-workflow:
-  mode: interactive
-
-sections:
-  - id: initial-setup
-    instruction: |
-    This template creates a comprehensive game architecture document specifically for Unity + C# projects. This should provide the technical foundation for all game development stories and epics.
-
-    If available, review any provided documents: Game Design Document (GDD), Technical Preferences. This architecture should support all game mechanics defined in the GDD.
-
-  - id: introduction
-    title: Introduction
-    instruction: Establish the document's purpose and scope for game development
-    content: |
-      This document outlines the complete technical architecture for {{Game Title}}, a 2D game built with Unity and C#. It serves as the technical foundation for AI-driven game development, ensuring consistency and scalability across all game systems.
-
-      This architecture is designed to support the gameplay mechanics defined in the Game Design Document while maintaining stable performance and cross-platform compatibility.
-    sections:
-      - id: change-log
-        title: Change Log
-        instruction: Track document versions and changes
-        type: table
-        template: |
-          | Date | Version | Description | Author |
-          | :--- | :------ | :---------- | :----- |
-
-  - id: technical-overview
-    title: Technical Overview
-    instruction: Present all subsections together, then apply `tasks#advanced-elicitation` protocol to the complete section.
-    sections:
-      - id: architecture-summary
-        title: Architecture Summary
-        instruction: |
-          Provide a comprehensive overview covering:
-
-          - Game engine choice and configuration
-          - Project structure and organization
-          - Key systems and their interactions
-          - Performance and optimization strategy
-          - How this architecture achieves GDD requirements
-      - id: platform-targets
-        title: Platform Targets
-        instruction: Based on GDD requirements, confirm platform support
-        template: |
-          **Primary Platform:** {{primary_platform}}
-          **Secondary Platforms:** {{secondary_platforms}}
-          **Minimum Requirements:** {{min_specs}}
-          **Target Performance:** Stable frame rate on {{target_device}}
-      - id: technology-stack
-        title: Technology Stack
-        template: |
-          **Core Engine:** Unity 2022 LTS or newer
-          **Language:** C# 10+
-          **Build Tool:** Unity Build Pipeline
-          **Package Manager:** Unity Package Manager
-          **Testing:** Unity Test Framework (NUnit)
-          **Deployment:** {{deployment_platform}}
-
-  - id: project-structure
-    title: Project Structure
-    instruction: Define the complete project organization that developers will follow
-    sections:
-      - id: repository-organization
-        title: Repository Organization
-        instruction: Design a clear folder structure for game development
-        type: code
-        language: text
-        template: |
-          {{game_name}}/
-          ├── Assets/
-          │   ├── Scenes/          # Game scenes
-          │   ├── Scripts/         # C# scripts
-          │   ├── Prefabs/         # Reusable game objects
-          │   ├── Art/             # Art assets
-          │   ├── Audio/           # Audio assets
-          │   ├── Data/            # ScriptableObjects and other data
-          │   └── Tests/           # Unity Test Framework tests
-          ├── Packages/            # Package Manager manifest
-          └── ProjectSettings/     # Unity project settings
-      - id: module-organization
-        title: Module Organization
-        instruction: Define how TypeScript modules should be organized
-        sections:
-          - id: scene-structure
-            title: Scene Structure
-            type: bullet-list
-            template: |
-              - Each scene in separate file
-              - Scene-specific logic contained in scripts within the scene
-              - Use a loading scene for asynchronous loading
-          - id: game-object-pattern
-            title: Game Object Pattern
-            type: bullet-list
-            template: |
-              - Component-based architecture using MonoBehaviours
-              - Reusable game objects as prefabs
-              - Data-driven design with ScriptableObjects
-          - id: system-architecture
-            title: System Architecture
-            type: bullet-list
-            template: |
-              - Singleton managers for global systems (e.g., GameManager, AudioManager)
-              - Event-driven communication using UnityEvents or C# events
-              - Clear separation of concerns between components
-
-  - id: core-game-systems
-    title: Core Game Systems
-    instruction: Detail each major system that needs to be implemented. Each system should be specific enough for developers to create implementation stories.
-    sections:
-      - id: scene-management
-        title: Scene Management System
-        template: |
-          **Purpose:** Handle game flow and scene transitions
-
-          **Key Components:**
-
-          - Asynchronous scene loading and unloading
-          - Data passing between scenes using a persistent manager or ScriptableObject
-          - Loading screens with progress bars
-
-          **Implementation Requirements:**
-
-          - A `SceneLoader` class to manage all scene transitions
-          - A loading scene to handle asynchronous loading
-          - A `GameManager` to persist between scenes and hold necessary data
-
-          **Files to Create:**
-
-          - `Assets/Scripts/Core/SceneLoader.cs`
-          - `Assets/Scenes/Loading.unity`
-      - id: game-state-management
-        title: Game State Management
-        template: |
-          **Purpose:** Track player progress and game status
-
-          **State Categories:**
-
-          - Player progress (levels, unlocks)
-          - Game settings (audio, controls)
-          - Session data (current level, score)
-          - Persistent data (achievements, statistics)
-
-          **Implementation Requirements:**
-
-          - A `SaveManager` class to handle saving and loading data to a file
-          - Use of `ScriptableObject`s to hold game state data
-          - State validation and error recovery
-
-          **Files to Create:**
-
-          - `Assets/Scripts/Core/SaveManager.cs`
-          - `Assets/Data/ScriptableObjects/GameState.cs`
-      - id: asset-management
-        title: Asset Management System
-        template: |
-          **Purpose:** Efficient loading and management of game assets
-
-          **Asset Categories:**
-
-          - Sprites and textures
-          - Audio clips and music
-          - Prefabs and scene files
-          - ScriptableObjects
-
-          **Implementation Requirements:**
-
-          - Use of Addressables for dynamic asset loading
-          - Asset bundles for platform-specific assets
-          - Memory management for large assets
-
-          **Files to Create:**
-
-          - `Assets/Scripts/Core/AssetManager.cs` (if needed for complex scenarios)
-      - id: input-management
-        title: Input Management System
-        template: |
-          **Purpose:** Handle all player input across platforms
-
-          **Input Types:**
-
-          - Keyboard controls
-          - Mouse/pointer interaction
-          - Touch gestures (mobile)
-          - Gamepad support
-
-          **Implementation Requirements:**
-
-          - Use the new Unity Input System
-          - Create Action Maps for different input contexts
-          - Use the `PlayerInput` component for easy player input handling
-
-          **Files to Create:**
-
-          - `Assets/Settings/InputActions.inputactions`
-      - id: game-mechanics-systems
-        title: Game Mechanics Systems
-        instruction: For each major mechanic defined in the GDD, create a system specification
-        repeatable: true
-        sections:
-          - id: mechanic-system
-            title: "{{mechanic_name}} System"
-            template: |
-              **Purpose:** {{system_purpose}}
-
-              **Core Functionality:**
-
-              - {{feature_1}}
-              - {{feature_2}}
-              - {{feature_3}}
-
-              **Dependencies:** {{required_systems}}
-
-              **Performance Considerations:** {{optimization_notes}}
-
-              **Files to Create:**
-
-              - `Assets/Scripts/Mechanics/{{SystemName}}.cs`
-              - `Assets/Prefabs/{{RelatedObject}}.prefab`
-      - id: physics-collision
-        title: Physics & Collision System
-        template: |
-          **Physics Engine:** Unity 2D Physics
-
-          **Collision Categories:**
-
-          - Player collision
-          - Enemy interactions
-          - Environmental objects
-          - Collectibles and items
-
-          **Implementation Requirements:**
-
-          - Use the Layer Collision Matrix to optimize collision detection
-          - Use `Rigidbody2D` for physics-based movement
-          - Use `Collider2D` components for collision shapes
-
-          **Files to Create:**
-
-          - (No new files, but configure `ProjectSettings/DynamicsManager.asset`)
-      - id: audio-system
-        title: Audio System
-        template: |
-          **Audio Requirements:**
-
-          - Background music with looping
-          - Sound effects for actions
-          - Audio settings and volume control
-          - Mobile audio optimization
-
-          **Implementation Features:**
-
-          - An `AudioManager` singleton to play sounds and music
-          - Use of `AudioMixer` to control volume levels
-          - Object pooling for frequently played sound effects
-
-          **Files to Create:**
-
-          - `Assets/Scripts/Core/AudioManager.cs`
-      - id: ui-system
-        title: UI System
-        template: |
-          **UI Components:**
-
-          - HUD elements (score, health, etc.)
-          - Menu navigation
-          - Modal dialogs
-          - Settings screens
-
-          **Implementation Requirements:**
-
-          - Use UI Toolkit or UGUI for building user interfaces
-          - Create a `UIManager` to manage UI elements
-          - Use events to update UI from game logic
-
-          **Files to Create:**
-
-          - `Assets/Scripts/UI/UIManager.cs`
-          - `Assets/UI/` (folder for UI assets and prefabs)
-
-  - id: performance-architecture
-    title: Performance Architecture
-    instruction: Define performance requirements and optimization strategies
-    sections:
-      - id: performance-targets
-        title: Performance Targets
-        template: |
-          **Frame Rate:** Stable frame rate, 60+ FPS on target platforms
-          **Memory Usage:** <{{memory_limit}}MB total
-          **Load Times:** <{{initial_load}}s initial, <{{level_load}}s per level
-          **Battery Optimization:** Reduced updates when not visible
-      - id: optimization-strategies
-        title: Optimization Strategies
-        sections:
-          - id: object-pooling
-            title: Object Pooling
-            type: bullet-list
-            template: |
-              - Bullets and projectiles
-              - Particle effects
-              - Enemy objects
-              - UI elements
-          - id: asset-optimization
-            title: Asset Optimization
-            type: bullet-list
-            template: |
-              - Sprite atlases
-              - Audio compression
-              - Mipmaps for textures
-          - id: rendering-optimization
-            title: Rendering Optimization
-            type: bullet-list
-            template: |
-              - Use the 2D Renderer
-              - Batching for sprites
-              - Culling off-screen objects
-          - id: optimization-files
-            title: Files to Create
-            type: bullet-list
-            template: |
-              - `Assets/Scripts/Core/ObjectPool.cs`
-
-  - id: game-configuration
-    title: Game Configuration
-    instruction: Define all configurable aspects of the game
-    sections:
-      - id: game-balance-configuration
-        title: Game Balance Configuration
-        instruction: Based on GDD, define configurable game parameters using ScriptableObjects
-        type: code
-        language: c#
-        template: |
-          // Assets/Scripts/Data/GameBalance.cs
-          using UnityEngine;
-
-          [CreateAssetMenu(fileName = "GameBalance", menuName = "Game/Game Balance")]
-          public class GameBalance : ScriptableObject
-          {
-              public PlayerStats playerStats;
-              public EnemyStats enemyStats;
-          }
-
-          [System.Serializable]
-          public class PlayerStats
-          {
-              public float speed;
-              public int maxHealth;
-          }
-
-          [System.Serializable]
-          public class EnemyStats
-          {
-              public float speed;
-              public int maxHealth;
-              public int damage;
-          }
-
-  - id: development-guidelines
-    title: Development Guidelines
-    instruction: Provide coding standards specific to game development
-    sections:
-      - id: c#-standards
-        title: C# Standards
-        sections:
-          - id: code-style
-            title: Code Style
-            type: bullet-list
-            template: |
-              - Follow .NET coding conventions
-              - Use namespaces to organize code
-              - Write clean, readable, and maintainable code
-      - id: unity-best-practices
-        title: Unity Best Practices
-        sections:
-          - id: general-best-practices
-            title: General Best Practices
-            type: bullet-list
-            template: |
-              - Use the `[SerializeField]` attribute to expose private fields in the Inspector
-              - Avoid using `GameObject.Find()` in `Update()`
-              - Cache component references in `Awake()` or `Start()`
-          - id: component-design
-            title: Component Design
-            type: bullet-list
-            template: |
-              - Follow the Single Responsibility Principle
-              - Use events for communication between components
-              - Use ScriptableObjects for data
-          - id: scene-management-practices
-            title: Scene Management
-            type: bullet-list
-            template: |
-              - Use a loading scene for asynchronous loading
-              - Keep scenes small and focused
-      - id: testing-strategy
-        title: Testing Strategy
-        sections:
-          - id: unit-testing
-            title: Unit Testing
-            type: bullet-list
-            template: |
-              - Use the Unity Test Framework (Edit Mode tests)
-              - Test C# logic in isolation
-          - id: integration-testing
-            title: Integration Testing
-            type: bullet-list
-            template: |
-              - Use the Unity Test Framework (Play Mode tests)
-              - Test the interaction between components and systems
-          - id: test-files
-            title: Files to Create
-            type: bullet-list
-            template: |
-              - `Assets/Tests/EditMode/`
-              - `Assets/Tests/PlayMode/`
-
-  - id: deployment-architecture
-    title: Deployment Architecture
-    instruction: Define how the game will be built and deployed
-    sections:
-      - id: build-process
-        title: Build Process
-        sections:
-          - id: development-build
-            title: Development Build
-            type: bullet-list
-            template: |
-              - Enable "Development Build" in Build Settings
-              - Use the Profiler to analyze performance
-          - id: production-build
-            title: Production Build
-            type: bullet-list
-            template: |
-              - Disable "Development Build"
-              - Use IL2CPP for better performance
-              - Configure platform-specific settings
-      - id: deployment-strategy
-        title: Deployment Strategy
-        sections:
-          - id: platform-deployment
-            title: Platform Deployment
-            type: bullet-list
-            template: |
-              - Configure player settings for each target platform
-              - Use Unity Cloud Build for automated builds
-              - Follow platform-specific guidelines for submission
-
-  - id: implementation-roadmap
-    title: Implementation Roadmap
-    instruction: Break down the architecture implementation into phases that align with the GDD development phases
-    sections:
-      - id: phase-1-foundation
-        title: "Phase 1: Foundation ({{duration}})"
-        sections:
-          - id: phase-1-core
-            title: Core Systems
-            type: bullet-list
-            template: |
-              - Project setup and configuration
-              - Basic scene management
-              - Asset loading pipeline
-              - Input handling framework
-          - id: phase-1-epics
-            title: Story Epics
-            type: bullet-list
-            template: |
-              - "Engine Setup and Configuration"
-              - "Basic Scene Management System"
-              - "Asset Loading Foundation"
-      - id: phase-2-game-systems
-        title: "Phase 2: Game Systems ({{duration}})"
-        sections:
-          - id: phase-2-gameplay
-            title: Gameplay Systems
-            type: bullet-list
-            template: |
-              - {{primary_mechanic}} implementation
-              - Physics and collision system
-              - Game state management
-              - UI framework
-          - id: phase-2-epics
-            title: Story Epics
-            type: bullet-list
-            template: |
-              - "{{primary_mechanic}} System Implementation"
-              - "Physics and Collision Framework"
-              - "Game State Management System"
-      - id: phase-3-content-polish
-        title: "Phase 3: Content & Polish ({{duration}})"
-        sections:
-          - id: phase-3-content
-            title: Content Systems
-            type: bullet-list
-            template: |
-              - Level loading and management
-              - Audio system integration
-              - Performance optimization
-              - Final polish and testing
-          - id: phase-3-epics
-            title: Story Epics
-            type: bullet-list
-            template: |
-              - "Level Management System"
-              - "Audio Integration and Optimization"
-              - "Performance Optimization and Testing"
-
-  - id: risk-assessment
-    title: Risk Assessment
-    instruction: Identify potential technical risks and mitigation strategies
-    type: table
-    template: |
-      | Risk                         | Probability | Impact     | Mitigation Strategy |
-      | ---------------------------- | ----------- | ---------- | ------------------- |
-      | Performance issues on mobile | {{prob}}    | {{impact}} | {{mitigation}}      |
-      | Asset loading bottlenecks    | {{prob}}    | {{impact}} | {{mitigation}}      |
-      | Cross-platform compatibility | {{prob}}    | {{impact}} | {{mitigation}}      |
-
-  - id: success-criteria
-    title: Success Criteria
-    instruction: Define measurable technical success criteria
-    sections:
-      - id: technical-metrics
-        title: Technical Metrics
-        type: bullet-list
-        template: |
-          - All systems implemented per specification
-          - Performance targets met consistently
-          - Zero critical bugs in core systems
-          - Successful deployment across target platforms
-      - id: code-quality
-        title: Code Quality
-        type: bullet-list
-        template: |
-          - 90%+ test coverage on game logic
-          - Zero C# compiler errors or warnings
-          - Consistent adherence to coding standards
-          - Comprehensive documentation coverage
-==================== END: .bmad-2d-unity-game-dev/templates/game-architecture-tmpl.yaml ====================
+==================== START: .bmad-2d-unity-game-dev/tasks/validate-next-story.md ====================
+# Validate Next Story Task
 
-==================== START: .bmad-2d-unity-game-dev/checklists/game-story-dod-checklist.md ====================
-# Game Development Story Definition of Done Checklist
-
-## Story Completeness
-
-### Basic Story Elements
-
-- [ ] **Story Title** - Clear, descriptive title that identifies the feature
-- [ ] **Epic Assignment** - Story is properly assigned to relevant epic
-- [ ] **Priority Level** - Appropriate priority assigned (High/Medium/Low)
-- [ ] **Story Points** - Realistic estimation for implementation complexity
-- [ ] **Description** - Clear, concise description of what needs to be implemented
-
-### Game Design Alignment
-
-- [ ] **GDD Reference** - Specific Game Design Document section referenced
-- [ ] **Game Mechanic Context** - Clear connection to game mechanics defined in GDD
-- [ ] **Player Experience Goal** - Describes the intended player experience
-- [ ] **Balance Parameters** - Includes any relevant game balance values
-- [ ] **Design Intent** - Purpose and rationale for the feature is clear
-
-## Technical Specifications
-
-### Architecture Compliance
-
-- [ ] **File Organization** - Follows game architecture document structure (e.g., scripts, prefabs, scenes)
-- [ ] **Class Definitions** - C# classes and interfaces are properly defined
-- [ ] **Integration Points** - Clear specification of how feature integrates with existing systems
-- [ ] **Event Communication** - UnityEvents or C# events usage specified
-- [ ] **Dependencies** - All system dependencies clearly identified
+## Purpose
 
-### Unity Requirements
+To comprehensively validate a story draft before implementation begins, ensuring it is complete, accurate, and provides sufficient context for successful development. This task identifies issues and gaps that need to be addressed, preventing hallucinations and ensuring implementation readiness.
 
-- [ ] **Scene Integration** - Specifies which scenes are affected and how
-- [ ] **Prefab Usage** - Proper use of prefabs for reusable GameObjects
-- [ ] **Component Design** - Logic is encapsulated in well-defined MonoBehaviour components
-- [ ] **Asset Requirements** - All needed assets (sprites, audio, materials) identified
-- [ ] **Performance Considerations** - Stable frame rate target and optimization requirements
+## SEQUENTIAL Task Execution (Do not proceed until current Task is complete)
 
-### Code Quality Standards
+### 0. Load Core Configuration and Inputs
 
-- [ ] **C# Best Practices** - All code must comply with modern C# standards
-- [ ] **Error Handling** - Error scenarios and handling requirements specified
-- [ ] **Memory Management** - Coroutine and object lifecycle management requirements where needed
-- [ ] **Cross-Platform Support** - Desktop and mobile considerations addressed
-- [ ] **Code Organization** - Follows established Unity project structure
+- Load `.bmad-core/core-config.yaml`
+- If the file does not exist, HALT and inform the user: "core-config.yaml not found. This file is required for story validation."
+- Extract key configurations: `devStoryLocation`, `prd.*`, `architecture.*`
+- Identify and load the following inputs:
+  - **Story file**: The drafted story to validate (provided by user or discovered in `devStoryLocation`)
+  - **Parent epic**: The epic containing this story's requirements
+  - **Architecture documents**: Based on configuration (sharded or monolithic)
+  - **Story template**: `bmad-core/templates/story-tmpl.md` for completeness validation
 
-## Implementation Readiness
+### 1. Template Completeness Validation
 
-### Acceptance Criteria
+- Load `bmad-core/templates/story-tmpl.md` and extract all section headings from the template
+- **Missing sections check**: Compare story sections against template sections to verify all required sections are present
+- **Placeholder validation**: Ensure no template placeholders remain unfilled (e.g., `{{EpicNum}}`, `{{role}}`, `_TBD_`)
+- **Agent section verification**: Confirm all sections from template exist for future agent use
+- **Structure compliance**: Verify story follows template structure and formatting
 
-- [ ] **Functional Requirements** - All functional acceptance criteria are specific and testable
-- [ ] **Technical Requirements** - Technical acceptance criteria are complete and verifiable
-- [ ] **Game Design Requirements** - Game-specific requirements match GDD specifications
-- [ ] **Performance Requirements** - Frame rate and memory usage criteria specified
-- [ ] **Completeness** - No acceptance criteria are vague or unmeasurable
+### 2. File Structure and Source Tree Validation
 
-### Implementation Tasks
+- **File paths clarity**: Are new/existing files to be created/modified clearly specified?
+- **Source tree relevance**: Is relevant project structure included in Dev Notes?
+- **Directory structure**: Are new directories/components properly located according to project structure?
+- **File creation sequence**: Do tasks specify where files should be created in logical order?
+- **Path accuracy**: Are file paths consistent with project structure from architecture docs?
 
-- [ ] **Task Breakdown** - Story broken into specific, ordered implementation tasks
-- [ ] **Task Scope** - Each task is completable in 1-4 hours
-- [ ] **Task Clarity** - Each task has clear, actionable instructions
-- [ ] **File Specifications** - Exact file paths and purposes specified (e.g., `Scripts/Player/PlayerMovement.cs`)
-- [ ] **Development Flow** - Tasks follow logical implementation order
+### 3. UI/Frontend Completeness Validation (if applicable)
 
-### Dependencies
+- **Component specifications**: Are UI components sufficiently detailed for implementation?
+- **Styling/design guidance**: Is visual implementation guidance clear?
+- **User interaction flows**: Are UX patterns and behaviors specified?
+- **Responsive/accessibility**: Are these considerations addressed if required?
+- **Integration points**: Are frontend-backend integration points clear?
 
-- [ ] **Story Dependencies** - All prerequisite stories identified with IDs
-- [ ] **Technical Dependencies** - Required systems and files identified
-- [ ] **Asset Dependencies** - All needed assets specified with locations
-- [ ] **External Dependencies** - Any third-party or external requirements noted (e.g., Asset Store packages)
-- [ ] **Dependency Validation** - All dependencies are actually available
+### 4. Acceptance Criteria Satisfaction Assessment
 
-## Testing Requirements
+- **AC coverage**: Will all acceptance criteria be satisfied by the listed tasks?
+- **AC testability**: Are acceptance criteria measurable and verifiable?
+- **Missing scenarios**: Are edge cases or error conditions covered?
+- **Success definition**: Is "done" clearly defined for each AC?
+- **Task-AC mapping**: Are tasks properly linked to specific acceptance criteria?
 
-### Test Coverage
+### 5. Validation and Testing Instructions Review
 
-- [ ] **Unit Test Requirements** - Specific unit test files and scenarios defined for NUnit
-- [ ] **Integration Test Cases** - Integration testing with other game systems specified
-- [ ] **Manual Test Cases** - Game-specific manual testing procedures defined in the Unity Editor
-- [ ] **Performance Tests** - Frame rate and memory testing requirements specified
-- [ ] **Edge Case Testing** - Edge cases and error conditions covered
+- **Test approach clarity**: Are testing methods clearly specified?
+- **Test scenarios**: Are key test cases identified?
+- **Validation steps**: Are acceptance criteria validation steps clear?
+- **Testing tools/frameworks**: Are required testing tools specified?
+- **Test data requirements**: Are test data needs identified?
 
-### Test Implementation
+### 6. Security Considerations Assessment (if applicable)
 
-- [ ] **Test File Paths** - Exact test file locations specified (e.g., `Assets/Tests/EditMode`)
-- [ ] **Test Scenarios** - All test scenarios are complete and executable
-- [ ] **Expected Behaviors** - Clear expected outcomes for all tests defined
-- [ ] **Performance Metrics** - Specific performance targets for testing
-- [ ] **Test Data** - Any required test data or mock objects specified
+- **Security requirements**: Are security needs identified and addressed?
+- **Authentication/authorization**: Are access controls specified?
+- **Data protection**: Are sensitive data handling requirements clear?
+- **Vulnerability prevention**: Are common security issues addressed?
+- **Compliance requirements**: Are regulatory/compliance needs addressed?
 
-## Game-Specific Quality
+### 7. Tasks/Subtasks Sequence Validation
 
-### Gameplay Implementation
+- **Logical order**: Do tasks follow proper implementation sequence?
+- **Dependencies**: Are task dependencies clear and correct?
+- **Granularity**: Are tasks appropriately sized and actionable?
+- **Completeness**: Do tasks cover all requirements and acceptance criteria?
+- **Blocking issues**: Are there any tasks that would block others?
 
-- [ ] **Mechanic Accuracy** - Implementation matches GDD mechanic specifications
-- [ ] **Player Controls** - Input handling requirements are complete (e.g., Input System package)
-- [ ] **Game Feel** - Requirements for juice, feedback, and responsiveness specified
-- [ ] **Balance Implementation** - Numeric values and parameters from GDD included
-- [ ] **State Management** - Game state changes and persistence requirements defined
+### 8. Anti-Hallucination Verification
 
-### User Experience
+- **Source verification**: Every technical claim must be traceable to source documents
+- **Architecture alignment**: Dev Notes content matches architecture specifications
+- **No invented details**: Flag any technical decisions not supported by source documents
+- **Reference accuracy**: Verify all source references are correct and accessible
+- **Fact checking**: Cross-reference claims against epic and architecture documents
 
-- [ ] **UI Requirements** - User interface elements and behaviors specified (e.g., UI Toolkit or UGUI)
-- [ ] **Audio Integration** - Sound effect and music requirements defined
-- [ ] **Visual Feedback** - Animation and visual effect requirements specified (e.g., Animator, Particle System)
-- [ ] **Accessibility** - Mobile touch and responsive design considerations
-- [ ] **Error Recovery** - User-facing error handling and recovery specified
+### 9. Dev Agent Implementation Readiness
 
-### Performance Optimization
+- **Self-contained context**: Can the story be implemented without reading external docs?
+- **Clear instructions**: Are implementation steps unambiguous?
+- **Complete technical context**: Are all required technical details present in Dev Notes?
+- **Missing information**: Identify any critical information gaps
+- **Actionability**: Are all tasks actionable by a development agent?
 
-- [ ] **Frame Rate Targets** - Specific FPS requirements for different platforms
-- [ ] **Memory Usage** - Memory consumption limits and monitoring requirements (e.g., Profiler)
-- [ ] **Asset Optimization** - Texture, audio, and data optimization requirements
-- [ ] **Mobile Considerations** - Touch controls and mobile performance requirements
-- [ ] **Loading Performance** - Asset loading and scene transition requirements
+### 10. Generate Validation Report
 
-## Documentation and Communication
+Provide a structured validation report including:
 
-### Story Documentation
+#### Template Compliance Issues
 
-- [ ] **Implementation Notes** - Additional context and implementation guidance provided
-- [ ] **Design Decisions** - Key design choices documented with rationale
-- [ ] **Future Considerations** - Potential future enhancements or modifications noted
-- [ ] **Change Tracking** - Process for tracking any requirement changes during development
-- [ ] **Reference Materials** - Links to relevant GDD sections and architecture docs
+- Missing sections from story template
+- Unfilled placeholders or template variables
+- Structural formatting issues
 
-### Developer Handoff
+#### Critical Issues (Must Fix - Story Blocked)
 
-- [ ] **Immediate Actionability** - Developer can start implementation without additional questions
-- [ ] **Complete Context** - All necessary context provided within the story
-- [ ] **Clear Boundaries** - What is and isn't included in the story scope is clear
-- [ ] **Success Criteria** - Objective measures for story completion defined
-- [ ] **Communication Plan** - Process for developer questions and updates established
+- Missing essential information for implementation
+- Inaccurate or unverifiable technical claims
+- Incomplete acceptance criteria coverage
+- Missing required sections
 
-## Final Validation
+#### Should-Fix Issues (Important Quality Improvements)
 
-### Story Readiness
+- Unclear implementation guidance
+- Missing security considerations
+- Task sequencing problems
+- Incomplete testing instructions
 
-- [ ] **No Ambiguity** - No sections require interpretation or additional design decisions
-- [ ] **Technical Completeness** - All technical requirements are specified and actionable
-- [ ] **Scope Appropriateness** - Story scope matches assigned story points
-- [ ] **Quality Standards** - Story meets all game development quality standards
-- [ ] **Review Completion** - Story has been reviewed for completeness and accuracy
+#### Nice-to-Have Improvements (Optional Enhancements)
 
-### Implementation Preparedness
+- Additional context that would help implementation
+- Clarifications that would improve efficiency
+- Documentation improvements
 
-- [ ] **Environment Ready** - Development environment requirements specified (e.g., Unity version)
-- [ ] **Resources Available** - All required resources (assets, docs, dependencies) accessible
-- [ ] **Testing Prepared** - Testing environment and data requirements specified
-- [ ] **Definition of Done** - Clear, objective completion criteria established
-- [ ] **Handoff Complete** - Story is ready for developer assignment and implementation
+#### Anti-Hallucination Findings
 
-## Checklist Completion
+- Unverifiable technical claims
+- Missing source references
+- Inconsistencies with architecture documents
+- Invented libraries, patterns, or standards
 
-**Overall Story Quality:** ⭐⭐⭐⭐⭐
+#### Final Assessment
 
-**Ready for Development:** [ ] Yes [ ] No
+- **GO**: Story is ready for implementation
+- **NO-GO**: Story requires fixes before implementation
+- **Implementation Readiness Score**: 1-10 scale
+- **Confidence Level**: High/Medium/Low for successful implementation
+==================== END: .bmad-2d-unity-game-dev/tasks/validate-next-story.md ====================
 
-**Additional Notes:**
-_Any specific concerns, recommendations, or clarifications needed before development begins._
-==================== END: .bmad-2d-unity-game-dev/checklists/game-story-dod-checklist.md ====================
-
-==================== START: .bmad-2d-unity-game-dev/data/development-guidelines.md ====================
-# Game Development Guidelines (Unity & C#)
-
-## Overview
-
-This document establishes coding standards, architectural patterns, and development practices for 2D game development using Unity and C#. These guidelines ensure consistency, performance, and maintainability across all game development stories.
-
-## C# Standards
-
-### Naming Conventions
-
-**Classes, Structs, Enums, and Interfaces:**
-- PascalCase for types: `PlayerController`, `GameData`, `IInteractable`
-- Prefix interfaces with 'I': `IDamageable`, `IControllable`
-- Descriptive names that indicate purpose: `GameStateManager` not `GSM`
-
-**Methods and Properties:**
-- PascalCase for methods and properties: `CalculateScore()`, `CurrentHealth`
-- Descriptive verb phrases for methods: `ActivateShield()` not `shield()`
-
-**Fields and Variables:**
-- `private` or `protected` fields: camelCase with an underscore prefix: `_playerHealth`, `_movementSpeed`
-- `public` fields (use sparingly, prefer properties): PascalCase: `PlayerName`
-- `static` fields: PascalCase: `Instance`, `GameVersion`
-- `const` fields: PascalCase: `MaxHitPoints`
-- `local` variables: camelCase: `damageAmount`, `isJumping`
-- Boolean variables with is/has/can prefix: `_isAlive`, `_hasKey`, `_canJump`
-
-**Files and Directories:**
-- PascalCase for C# script files, matching the primary class name: `PlayerController.cs`
-- PascalCase for Scene files: `MainMenu.unity`, `Level01.unity`
-
-### Style and Formatting
-
-- **Braces**: Use Allman style (braces on a new line).
-- **Spacing**: Use 4 spaces for indentation (no tabs).
-- **`using` directives**: Place all `using` directives at the top of the file, outside the namespace.
-- **`this` keyword**: Only use `this` when necessary to distinguish between a field and a local variable/parameter.
-
-## Unity Architecture Patterns
-
-### Scene Lifecycle Management
-**Loading and Transitioning Between Scenes:**
-```csharp
-// SceneLoader.cs - A singleton for managing scene transitions.
-using UnityEngine;
-using UnityEngine.SceneManagement;
-using System.Collections;
-
-public class SceneLoader : MonoBehaviour
-{
-    public static SceneLoader Instance { get; private set; }
-
-    private void Awake()
-    {
-        if (Instance != null && Instance != this)
-        {
-            Destroy(gameObject);
-            return;
-        }
-        Instance = this;
-        DontDestroyOnLoad(gameObject);
-    }
-
-    public void LoadGameScene()
-    {
-        // Example of loading the main game scene, perhaps with a loading screen first.
-        StartCoroutine(LoadSceneAsync("Level01"));
-    }
-
-    private IEnumerator LoadSceneAsync(string sceneName)
-    {
-        // Load a loading screen first (optional)
-        SceneManager.LoadScene("LoadingScreen");
-
-        // Wait a frame for the loading screen to appear
-        yield return null;
-
-        // Begin loading the target scene in the background
-        AsyncOperation asyncLoad = SceneManager.LoadSceneAsync(sceneName);
-
-        // Don't activate the scene until it's fully loaded
-        asyncLoad.allowSceneActivation = false;
-
-        // Wait until the asynchronous scene fully loads
-        while (!asyncLoad.isDone)
-        {
-            // Here you could update a progress bar with asyncLoad.progress
-            if (asyncLoad.progress >= 0.9f)
-            {
-                // Scene is loaded, allow activation
-                asyncLoad.allowSceneActivation = true;
-            }
-            yield return null;
-        }
-    }
-}
-```
-
-### MonoBehaviour Lifecycle
-**Understanding Core MonoBehaviour Events:**
-```csharp
-// Example of a standard MonoBehaviour lifecycle
-using UnityEngine;
-
-public class PlayerController : MonoBehaviour
-{
-    // AWAKE: Called when the script instance is being loaded.
-    // Use for initialization before the game starts. Good for caching component references.
-    private void Awake()
-    {
-        Debug.Log("PlayerController Awake!");
-    }
-
-    // ONENABLE: Called when the object becomes enabled and active.
-    // Good for subscribing to events.
-    private void OnEnable()
-    {
-        // Example: UIManager.OnGamePaused += HandleGamePaused;
-    }
-
-    // START: Called on the frame when a script is enabled just before any of the Update methods are called the first time.
-    // Good for logic that depends on other objects being initialized.
-    private void Start()
-    {
-        Debug.Log("PlayerController Start!");
-    }
-
-    // FIXEDUPDATE: Called every fixed framerate frame.
-    // Use for physics calculations (e.g., applying forces to a Rigidbody).
-    private void FixedUpdate()
-    {
-        // Handle Rigidbody movement here.
-    }
-
-    // UPDATE: Called every frame.
-    // Use for most game logic, like handling input and non-physics movement.
-    private void Update()
-    {
-        // Handle input and non-physics movement here.
-    }
-    
-    // LATEUPDATE: Called every frame, after all Update functions have been called.
-    // Good for camera logic that needs to track a target that moves in Update.
-    private void LateUpdate()
-    {
-        // Camera follow logic here.
-    }
-
-    // ONDISABLE: Called when the behaviour becomes disabled or inactive.
-    // Good for unsubscribing from events to prevent memory leaks.
-    private void OnDisable()
-    {
-        // Example: UIManager.OnGamePaused -= HandleGamePaused;
-    }
-
-    // ONDESTROY: Called when the MonoBehaviour will be destroyed.
-    // Good for any final cleanup.
-    private void OnDestroy()
-    {
-        Debug.Log("PlayerController Destroyed!");
-    }
-}
-```
-
-### Game Object Patterns
-
-**Component-Based Architecture:**
-```csharp
-// Player.cs - The main GameObject class, acts as a container for components.
-using UnityEngine;
-
-[RequireComponent(typeof(PlayerMovement), typeof(PlayerHealth))]
-public class Player : MonoBehaviour
-{
-    public PlayerMovement Movement { get; private set; }
-    public PlayerHealth Health { get; private set; }
-
-    private void Awake()
-    {
-        Movement = GetComponent<PlayerMovement>();
-        Health = GetComponent<PlayerHealth>();
-    }
-}
-
-// PlayerHealth.cs - A component responsible only for health logic.
-public class PlayerHealth : MonoBehaviour
-{
-    [SerializeField] private int _maxHealth = 100;
-    private int _currentHealth;
-
-    private void Awake()
-    {
-        _currentHealth = _maxHealth;
-    }
-
-    public void TakeDamage(int amount)
-    {
-        _currentHealth -= amount;
-        if (_currentHealth <= 0)
-        {
-            Die();
-        }
-    }
-
-    private void Die()
-    {
-        // Death logic
-        Debug.Log("Player has died.");
-        gameObject.SetActive(false);
-    }
-}
-```
-
-### Data-Driven Design with ScriptableObjects
-
-**Define Data Containers:**
-```csharp
-// EnemyData.cs - A ScriptableObject to hold data for an enemy type.
-using UnityEngine;
-
-[CreateAssetMenu(fileName = "NewEnemyData", menuName = "Game/Enemy Data")]
-public class EnemyData : ScriptableObject
-{
-    public string enemyName;
-    public int maxHealth;
-    public float moveSpeed;
-    public int damage;
-    public Sprite sprite;
-}
-
-// Enemy.cs - A MonoBehaviour that uses the EnemyData.
-public class Enemy : MonoBehaviour
-{
-    [SerializeField] private EnemyData _enemyData;
-    private int _currentHealth;
-
-    private void Start()
-    {
-        _currentHealth = _enemyData.maxHealth;
-        GetComponent<SpriteRenderer>().sprite = _enemyData.sprite;
-    }
-    
-    // ... other enemy logic
-}
-```
+==================== START: .bmad-2d-unity-game-dev/checklists/game-story-dod-checklist.md ====================
+# Game Development Story Definition of Done (DoD) Checklist
 
-### System Management
-
-**Singleton Managers:**
-```csharp
-// GameManager.cs - A singleton to manage the overall game state.
-using UnityEngine;
-
-public class GameManager : MonoBehaviour
-{
-    public static GameManager Instance { get; private set; }
-
-    public int Score { get; private set; }
-
-    private void Awake()
-    {
-        if (Instance != null && Instance != this)
-        {
-            Destroy(gameObject);
-            return;
-        }
-        Instance = this;
-        DontDestroyOnLoad(gameObject); // Persist across scenes
-    }
-
-    public void AddScore(int amount)
-    {
-        Score += amount;
-    }
-}
-```
+## Instructions for Developer Agent
 
-## Performance Optimization
-
-### Object Pooling
-
-**Required for High-Frequency Objects (e.g., bullets, effects):**
-```csharp
-// ObjectPool.cs - A generic object pooling system.
-using UnityEngine;
-using System.Collections.Generic;
-
-public class ObjectPool : MonoBehaviour
-{
-    [SerializeField] private GameObject _prefabToPool;
-    [SerializeField] private int _initialPoolSize = 20;
-
-    private Queue<GameObject> _pool = new Queue<GameObject>();
-
-    private void Start()
-    {
-        for (int i = 0; i < _initialPoolSize; i++)
-        {
-            GameObject obj = Instantiate(_prefabToPool);
-            obj.SetActive(false);
-            _pool.Enqueue(obj);
-        }
-    }
-
-    public GameObject GetObjectFromPool()
-    {
-        if (_pool.Count > 0)
-        {
-            GameObject obj = _pool.Dequeue();
-            obj.SetActive(true);
-            return obj;
-        }
-        // Optionally, expand the pool if it's empty.
-        return Instantiate(_prefabToPool);
-    }
-
-    public void ReturnObjectToPool(GameObject obj)
-    {
-        obj.SetActive(false);
-        _pool.Enqueue(obj);
-    }
-}
-```
+Before marking a story as 'Review', please go through each item in this checklist. Report the status of each item (e.g., [x] Done, [ ] Not Done, [N/A] Not Applicable) and provide brief comments if necessary.
 
-### Frame Rate Optimization
+[[LLM: INITIALIZATION INSTRUCTIONS - GAME STORY DOD VALIDATION
 
-**Update Loop Optimization:**
-- Avoid expensive calls like `GetComponent`, `FindObjectOfType`, or `Instantiate` inside `Update()` or `FixedUpdate()`. Cache references in `Awake()` or `Start()`.
-- Use Coroutines or simple timers for logic that doesn't need to run every single frame.
+This checklist is for GAME DEVELOPER AGENTS to self-validate their work before marking a story complete.
 
-**Physics Optimization:**
-- Adjust the "Physics 2D Settings" in Project Settings, especially the "Layer Collision Matrix", to prevent unnecessary collision checks.
-- Use `Rigidbody2D.Sleep()` for objects that are not moving to save CPU cycles.
+IMPORTANT: This is a self-assessment. Be honest about what's actually done vs what should be done. It's better to identify issues now than have them found in review.
 
-## Input Handling
+EXECUTION APPROACH:
 
-### Cross-Platform Input (New Input System)
+1. Go through each section systematically
+2. Mark items as [x] Done, [ ] Not Done, or [N/A] Not Applicable
+3. Add brief comments explaining any [ ] or [N/A] items
+4. Be specific about what was actually implemented
+5. Flag any concerns or technical debt created
 
-**Input Action Asset:** Create an Input Action Asset (`.inputactions`) to define controls.
+The goal is quality delivery, not just checking boxes.]]
 
-**PlayerInput Component:**
-- Add the `PlayerInput` component to the player GameObject.
-- Set its "Actions" to the created Input Action Asset.
-- Set "Behavior" to "Invoke Unity Events" to easily hook up methods in the Inspector, or "Send Messages" to use methods like `OnMove`, `OnFire`.
+## Checklist Items
 
-```csharp
-// PlayerInputHandler.cs - Example of handling input via messages.
-using UnityEngine;
-using UnityEngine.InputSystem;
+1. **Requirements Met:**
 
-public class PlayerInputHandler : MonoBehaviour
-{
-    private Vector2 _moveInput;
+   [[LLM: Be specific - list each requirement and whether it's complete. Include game-specific requirements from GDD]]
 
-    // This method is called by the PlayerInput component via "Send Messages".
-    // The action must be named "Move" in the Input Action Asset.
-    public void OnMove(InputValue value)
-    {
-        _moveInput = value.Get<Vector2>();
-    }
+   - [ ] All functional requirements specified in the story are implemented.
+   - [ ] All acceptance criteria defined in the story are met.
+   - [ ] Game Design Document (GDD) requirements referenced in the story are implemented.
+   - [ ] Player experience goals specified in the story are achieved.
 
-    private void Update()
-    {
-        // Use _moveInput to control the player
-        transform.Translate(new Vector3(_moveInput.x, _moveInput.y, 0) * Time.deltaTime * 5f);
-    }
-}
-```
+2. **Coding Standards & Project Structure:**
 
-## Error Handling
+   [[LLM: Code quality matters for maintainability. Check Unity-specific patterns and C# standards]]
 
-### Graceful Degradation
+   - [ ] All new/modified code strictly adheres to `Operational Guidelines`.
+   - [ ] All new/modified code aligns with `Project Structure` (Scripts/, Prefabs/, Scenes/, etc.).
+   - [ ] Adherence to `Tech Stack` for Unity version and packages used.
+   - [ ] Adherence to `Api Reference` and `Data Models` (if story involves API or data model changes).
+   - [ ] Unity best practices followed (prefab usage, component design, event handling).
+   - [ ] C# coding standards followed (naming conventions, error handling, memory management).
+   - [ ] Basic security best practices applied for new/modified code.
+   - [ ] No new linter errors or warnings introduced.
+   - [ ] Code is well-commented where necessary (clarifying complex logic, not obvious statements).
 
-**Asset Loading Error Handling:**
-- When using Addressables or `Resources.Load`, always check if the loaded asset is null before using it.
-```csharp
-// Load a sprite and use a fallback if it fails
-Sprite playerSprite = Resources.Load<Sprite>("Sprites/Player");
-if (playerSprite == null)
-{
-    Debug.LogError("Player sprite not found! Using default.");
-    playerSprite = Resources.Load<Sprite>("Sprites/Default");
-}
-```
+3. **Testing:**
 
-### Runtime Error Recovery
+   [[LLM: Testing proves your code works. Include Unity-specific testing with NUnit and manual testing]]
 
-**Assertions and Logging:**
-- Use `Debug.Assert(condition, "Message")` to check for critical conditions that must be true.
-- Use `Debug.LogError("Message")` for fatal errors and `Debug.LogWarning("Message")` for non-critical issues.
-```csharp
-// Example of using an assertion to ensure a component exists.
-private Rigidbody2D _rb;
+   - [ ] All required unit tests (NUnit) as per the story and testing strategy are implemented.
+   - [ ] All required integration tests (if applicable) are implemented.
+   - [ ] Manual testing performed in Unity Editor for all game functionality.
+   - [ ] All tests (unit, integration, manual) pass successfully.
+   - [ ] Test coverage meets project standards (if defined).
+   - [ ] Performance tests conducted (frame rate, memory usage).
+   - [ ] Edge cases and error conditions tested.
 
-void Awake()
-{
-    _rb = GetComponent<Rigidbody2D>();
-    Debug.Assert(_rb != null, "Rigidbody2D component not found on player!");
-}
-```
+4. **Functionality & Verification:**
 
-## Testing Standards
-
-### Unit Testing (Edit Mode)
-
-**Game Logic Testing:**
-```csharp
-// HealthSystemTests.cs - Example test for a simple health system.
-using NUnit.Framework;
-using UnityEngine;
-
-public class HealthSystemTests
-{
-    [Test]
-    public void TakeDamage_ReducesHealth()
-    {
-        // Arrange
-        var gameObject = new GameObject();
-        var healthSystem = gameObject.AddComponent<PlayerHealth>();
-        // Note: This is a simplified example. You might need to mock dependencies.
-        
-        // Act
-        healthSystem.TakeDamage(20);
-
-        // Assert
-        // This requires making health accessible for testing, e.g., via a public property or method.
-        // Assert.AreEqual(80, healthSystem.CurrentHealth);
-    }
-}
-```
+   [[LLM: Did you actually run and test your code in Unity? Be specific about game mechanics tested]]
 
-### Integration Testing (Play Mode)
-
-**Scene Testing:**
-- Play Mode tests run in a live scene, allowing you to test interactions between multiple components and systems.
-- Use `yield return null;` to wait for the next frame.
-```csharp
-// PlayerJumpTest.cs
-using System.Collections;
-using NUnit.Framework;
-using UnityEngine;
-using UnityEngine.TestTools;
-
-public class PlayerJumpTest
-{
-    [UnityTest]
-    public IEnumerator PlayerJumps_WhenSpaceIsPressed()
-    {
-        // Arrange
-        var player = new GameObject().AddComponent<PlayerController>();
-        var initialY = player.transform.position.y;
-
-        // Act
-        // Simulate pressing the jump button (requires setting up the input system for tests)
-        // For simplicity, we'll call a public method here.
-        // player.Jump(); 
-
-        // Wait for a few physics frames
-        yield return new WaitForSeconds(0.5f);
-
-        // Assert
-        Assert.Greater(player.transform.position.y, initialY);
-    }
-}
-```
+   - [ ] Functionality has been manually verified in Unity Editor and play mode.
+   - [ ] Game mechanics work as specified in the GDD.
+   - [ ] Player controls and input handling work correctly.
+   - [ ] UI elements function properly (if applicable).
+   - [ ] Audio integration works correctly (if applicable).
+   - [ ] Visual feedback and animations work as intended.
+   - [ ] Edge cases and potential error conditions handled gracefully.
+   - [ ] Cross-platform functionality verified (desktop/mobile as applicable).
 
-## File Organization
+5. **Story Administration:**
 
-### Project Structure
+   [[LLM: Documentation helps the next developer. Include Unity-specific implementation notes]]
 
-```
-Assets/
-├── Scenes/
-│   ├── MainMenu.unity
-│   └── Level01.unity
-├── Scripts/
-│   ├── Core/
-│   │   ├── GameManager.cs
-│   │   └── AudioManager.cs
-│   ├── Player/
-│   │   ├── PlayerController.cs
-│   │   └── PlayerHealth.cs
-│   ├── Editor/
-│   │   └── CustomInspectors.cs
-│   └── Data/
-│       └── EnemyData.cs
-├── Prefabs/
-│   ├── Player.prefab
-│   └── Enemies/
-│       └── Slime.prefab
-├── Art/
-│   ├── Sprites/
-│   └── Animations/
-├── Audio/
-│   ├── Music/
-│   └── SFX/
-├── Data/
-│   └── ScriptableObjects/
-│       └── EnemyData/
-└── Tests/
-    ├── EditMode/
-    │   └── HealthSystemTests.cs
-    └── PlayMode/
-        └── PlayerJumpTest.cs
-```
-
-## Development Workflow
-
-### Story Implementation Process
-
-1. **Read Story Requirements:**
+   - [ ] All tasks within the story file are marked as complete.
+   - [ ] Any clarifications or decisions made during development are documented.
+   - [ ] Unity-specific implementation details documented (scene changes, prefab modifications).
+   - [ ] The story wrap up section has been completed with notes of changes.
+   - [ ] Changelog properly updated with Unity version and package changes.
 
-   - Understand acceptance criteria
-   - Identify technical requirements
-   - Review performance constraints
+6. **Dependencies, Build & Configuration:**
 
-2. **Plan Implementation:**
+   [[LLM: Build issues block everyone. Ensure Unity project builds for all target platforms]]
 
-   - Identify files to create/modify
-   - Consider Unity's component-based architecture
-   - Plan testing approach
+   - [ ] Unity project builds successfully without errors.
+   - [ ] Project builds for all target platforms (desktop/mobile as specified).
+   - [ ] Any new Unity packages or Asset Store items were pre-approved OR approved by user.
+   - [ ] If new dependencies were added, they are recorded with justification.
+   - [ ] No known security vulnerabilities in newly added dependencies.
+   - [ ] Project settings and configurations properly updated.
+   - [ ] Asset import settings optimized for target platforms.
 
-3. **Implement Feature:**
+7. **Game-Specific Quality:**
 
-   - Write clean C# code following all guidelines
-   - Use established patterns
-   - Maintain stable FPS performance
+   [[LLM: Game quality matters. Check performance, game feel, and player experience]]
 
-4. **Test Implementation:**
+   - [ ] Frame rate meets target (30/60 FPS) on all platforms.
+   - [ ] Memory usage within acceptable limits.
+   - [ ] Game feel and responsiveness meet design requirements.
+   - [ ] Balance parameters from GDD correctly implemented.
+   - [ ] State management and persistence work correctly.
+   - [ ] Loading times and scene transitions acceptable.
+   - [ ] Mobile-specific requirements met (touch controls, aspect ratios).
 
-   - Write edit mode tests for game logic
-   - Write play mode tests for integration testing
-   - Test cross-platform functionality
-   - Validate performance targets
+8. **Documentation (If Applicable):**
 
-5. **Update Documentation:**
-   - Mark story checkboxes complete
-   - Document any deviations
-   - Update architecture if needed
+   [[LLM: Good documentation prevents future confusion. Include Unity-specific docs]]
 
-### Code Review Checklist
+   - [ ] Code documentation (XML comments) for public APIs complete.
+   - [ ] Unity component documentation in Inspector updated.
+   - [ ] User-facing documentation updated, if changes impact players.
+   - [ ] Technical documentation (architecture, system diagrams) updated.
+   - [ ] Asset documentation (prefab usage, scene setup) complete.
 
-- [ ] C# code compiles without errors or warnings.
-- [ ] All automated tests pass.
-- [ ] Code follows naming conventions and architectural patterns.
-- [ ] No expensive operations in `Update()` loops.
-- [ ] Public fields/methods are documented with comments.
-- [ ] New assets are organized into the correct folders.
+## Final Confirmation
 
-## Performance Targets
+[[LLM: FINAL GAME DOD SUMMARY
 
-### Frame Rate Requirements
+After completing the checklist:
 
-- **PC/Console**: Maintain a stable 60+ FPS.
-- **Mobile**: Maintain 60 FPS on mid-range devices, minimum 30 FPS on low-end.
-- **Optimization**: Use the Unity Profiler to identify and fix performance drops.
+1. Summarize what game features/mechanics were implemented
+2. List any items marked as [ ] Not Done with explanations
+3. Identify any technical debt or performance concerns
+4. Note any challenges with Unity implementation or game design
+5. Confirm whether the story is truly ready for review
+6. Report final performance metrics (FPS, memory usage)
 
-### Memory Management
+Be honest - it's better to flag issues now than have them discovered during playtesting.]]
 
-- **Total Memory**: Keep builds under platform-specific limits (e.g., 200MB for a simple mobile game).
-- **Garbage Collection**: Minimize GC spikes by avoiding string concatenation, `new` keyword usage in loops, and by pooling objects.
-
-### Loading Performance
-
-- **Initial Load**: Under 5 seconds for game start.
-- **Scene Transitions**: Under 2 seconds between scenes. Use asynchronous scene loading.
-
-These guidelines ensure consistent, high-quality game development that meets performance targets and maintains code quality across all implementation stories.
-==================== END: .bmad-2d-unity-game-dev/data/development-guidelines.md ====================
+- [ ] I, the Game Developer Agent, confirm that all applicable items above have been addressed.
+==================== END: .bmad-2d-unity-game-dev/checklists/game-story-dod-checklist.md ====================