bmad-method 4.37.0 → 4.39.1

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

@@ -108,7 +108,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
 ## Instructions
 
 1. **Initial Assessment**
-
    - If user or the task being run provides a checklist name:
      - Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
      - If multiple matches found, ask user to clarify
@@ -121,14 +120,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
      - All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
 
 2. **Document and Artifact Gathering**
-
    - Each checklist will specify its required documents/artifacts at the beginning
    - Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
 
 3. **Checklist Processing**
 
    If in interactive mode:
-
    - Work through each section of the checklist one at a time
    - For each section:
      - Review all items in the section following instructions for that section embedded in the checklist
@@ -137,7 +134,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
      - Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
 
    If in YOLO mode:
-
    - Process all sections at once
    - Create a comprehensive report of all findings
    - Present the complete analysis to the user
@@ -145,7 +141,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
 4. **Validation Approach**
 
    For each checklist item:
-
    - Read and understand the requirement
    - Look for evidence in the documentation that satisfies the requirement
    - Consider both explicit mentions and implicit coverage
@@ -159,7 +154,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
 5. **Section Analysis**
 
    For each section:
-
    - think step by step to calculate pass rate
    - Identify common themes in failed items
    - Provide specific recommendations for improvement
@@ -169,7 +163,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
 6. **Final Report**
 
    Prepare a summary that includes:
-
    - Overall checklist completion status
    - Pass rates by section
    - List of failed items with context
@@ -357,7 +350,6 @@ The goal is quality delivery, not just checking boxes.]]
 1. **Requirements Met:**
 
    [[LLM: Be specific - list each requirement and whether it's complete. Include game-specific requirements from GDD]]
-
    - [ ] 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.
@@ -366,7 +358,6 @@ The goal is quality delivery, not just checking boxes.]]
 2. **Coding Standards & Project Structure:**
 
    [[LLM: Code quality matters for maintainability. Check Unity-specific patterns and C# standards]]
-
    - [ ] 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.
@@ -380,7 +371,6 @@ The goal is quality delivery, not just checking boxes.]]
 3. **Testing:**
 
    [[LLM: Testing proves your code works. Include Unity-specific testing with NUnit and manual testing]]
-
    - [ ] 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.
@@ -392,7 +382,6 @@ The goal is quality delivery, not just checking boxes.]]
 4. **Functionality & Verification:**
 
    [[LLM: Did you actually run and test your code in Unity? Be specific about game mechanics tested]]
-
    - [ ] 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.
@@ -405,7 +394,6 @@ The goal is quality delivery, not just checking boxes.]]
 5. **Story Administration:**
 
    [[LLM: Documentation helps the next developer. Include Unity-specific implementation notes]]
-
    - [ ] 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).
@@ -415,7 +403,6 @@ The goal is quality delivery, not just checking boxes.]]
 6. **Dependencies, Build & Configuration:**
 
    [[LLM: Build issues block everyone. Ensure Unity project builds for all target platforms]]
-
    - [ ] 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.
@@ -427,7 +414,6 @@ The goal is quality delivery, not just checking boxes.]]
 7. **Game-Specific Quality:**
 
    [[LLM: Game quality matters. Check performance, game feel, and player experience]]
-
    - [ ] Frame rate meets target (30/60 FPS) on all platforms.
    - [ ] Memory usage within acceptable limits.
    - [ ] Game feel and responsiveness meet design requirements.
@@ -439,7 +425,6 @@ The goal is quality delivery, not just checking boxes.]]
 8. **Documentation (If Applicable):**
 
    [[LLM: Good documentation prevents future confusion. Include Unity-specific docs]]
-
    - [ ] Code documentation (XML comments) for public APIs complete.
    - [ ] Unity component documentation in Inspector updated.
    - [ ] User-facing documentation updated, if changes impact players.

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

@@ -286,7 +286,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
 ## Instructions
 
 1. **Initial Assessment**
-
    - If user or the task being run provides a checklist name:
      - Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
      - If multiple matches found, ask user to clarify
@@ -299,14 +298,12 @@ If the user asks or does not specify a specific checklist, list the checklists a
      - All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
 
 2. **Document and Artifact Gathering**
-
    - Each checklist will specify its required documents/artifacts at the beginning
    - Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
 
 3. **Checklist Processing**
 
    If in interactive mode:
-
    - Work through each section of the checklist one at a time
    - For each section:
      - Review all items in the section following instructions for that section embedded in the checklist
@@ -315,7 +312,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
      - Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
 
    If in YOLO mode:
-
    - Process all sections at once
    - Create a comprehensive report of all findings
    - Present the complete analysis to the user
@@ -323,7 +319,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
 4. **Validation Approach**
 
    For each checklist item:
-
    - Read and understand the requirement
    - Look for evidence in the documentation that satisfies the requirement
    - Consider both explicit mentions and implicit coverage
@@ -337,7 +332,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
 5. **Section Analysis**
 
    For each section:
-
    - think step by step to calculate pass rate
    - Identify common themes in failed items
    - Provide specific recommendations for improvement
@@ -347,7 +341,6 @@ If the user asks or does not specify a specific checklist, list the checklists a
 6. **Final Report**
 
    Prepare a summary that includes:
-
    - Overall checklist completion status
    - Pass rates by section
    - List of failed items with context
@@ -387,7 +380,6 @@ The LLM will:
 ### 1. Initial Setup & Mode Selection
 
 - **Acknowledge Task & Inputs:**
-
   - Confirm with the user that the "Game Development Correct Course Task" is being initiated.
   - Verify the change trigger (e.g., performance issue, platform constraint, gameplay feedback, technical blocker).
   - Confirm access to relevant game artifacts:
@@ -408,7 +400,6 @@ The LLM will:
 ### 2. Execute Game Development Checklist Analysis
 
 - Systematically work through the game-change-checklist sections:
-
   1. **Change Context & Game Impact**
   2. **Feature/System Impact Analysis**
   3. **Technical Artifact Conflict Resolution**
@@ -433,7 +424,6 @@ The LLM will:
 Based on the analysis and agreed path forward:
 
 - **Identify affected game artifacts requiring updates:**
-
   - GDD sections (mechanics, systems, progression)
   - Technical specifications (architecture, performance targets)
   - Unity-specific configurations (build settings, quality settings)
@@ -442,7 +432,6 @@ Based on the analysis and agreed path forward:
   - Platform-specific adaptations
 
 - **Draft explicit changes for each artifact:**
-
   - **Game Stories:** Revise story text, Unity-specific acceptance criteria, technical constraints
   - **Technical Specs:** Update architecture diagrams, component hierarchies, performance budgets
   - **Unity Configurations:** Propose settings changes, optimization strategies, platform variants
@@ -462,14 +451,12 @@ Based on the analysis and agreed path forward:
 - Create a comprehensive proposal document containing:
 
   **A. Change Summary:**
-
   - Original issue (performance, gameplay, technical constraint)
   - Game systems affected
   - Platform/performance implications
   - Chosen solution approach
 
   **B. Technical Impact Analysis:**
-
   - Unity architecture changes needed
   - Performance implications (with metrics)
   - Platform compatibility effects
@@ -477,14 +464,12 @@ Based on the analysis and agreed path forward:
   - Third-party dependency impacts
 
   **C. Specific Proposed Edits:**
-
   - For each game story: "Change Story GS-X.Y from: [old] To: [new]"
   - For technical specs: "Update Unity Architecture Section X: [changes]"
   - For GDD: "Modify [Feature] in Section Y: [updates]"
   - For configurations: "Change [Setting] from [old_value] to [new_value]"
 
   **D. Implementation Considerations:**
-
   - Required Unity version updates
   - Asset reimport needs
   - Shader recompilation requirements
@@ -496,7 +481,6 @@ Based on the analysis and agreed path forward:
 - Provide the finalized document to the user
 
 - **Based on change scope:**
-
   - **Minor adjustments (can be handled in current sprint):**
     - Confirm task completion
     - Suggest handoff to game-dev agent for implementation
@@ -510,7 +494,6 @@ Based on the analysis and agreed path forward:
 ## Output Deliverables
 
 - **Primary:** "Game Development Change Proposal" document containing:
-
   - Game-specific change analysis
   - Technical impact assessment with Unity context
   - Platform and performance considerations
@@ -541,13 +524,13 @@ sections:
   - id: initial-setup
     instruction: |
       This template creates detailed game development stories that are immediately actionable by game developers. Each story should focus on a single, implementable feature that contributes to the overall game functionality.
-      
+
       Before starting, ensure you have access to:
-      
+
       - Game Design Document (GDD)
       - Game Architecture Document
       - Any existing stories in this epic
-      
+
       The story should be specific enough that a developer can implement it without requiring additional design decisions.
 
   - id: story-header
@@ -596,12 +579,12 @@ sections:
         title: Files to Create/Modify
         template: |
           **New Files:**
-          
+
           - `{{file_path_1}}` - {{purpose}}
           - `{{file_path_2}}` - {{purpose}}
-          
+
           **Modified Files:**
-          
+
           - `{{existing_file_1}}` - {{changes_needed}}
           - `{{existing_file_2}}` - {{changes_needed}}
       - id: class-interface-definitions
@@ -684,13 +667,13 @@ sections:
     instruction: Reference the specific sections of the GDD that this story implements
     template: |
       **GDD Reference:** {{section_name}} ({{page_or_section_number}})
-      
+
       **Game Mechanic:** {{mechanic_name}}
-      
+
       **Player Experience Goal:** {{experience_description}}
-      
+
       **Balance Parameters:**
-      
+
       - {{parameter_1}}: {{value_or_range}}
       - {{parameter_2}}: {{value_or_range}}
 
@@ -737,15 +720,15 @@ sections:
     instruction: List any dependencies that must be completed before this story can be implemented
     template: |
       **Story Dependencies:**
-      
+
       - {{story_id}}: {{dependency_description}}
-      
+
       **Technical Dependencies:**
-      
+
       - {{system_or_file}}: {{requirement}}
-      
+
       **Asset Dependencies:**
-      
+
       - {{asset_type}}: {{asset_description}}
       - Location: `{{asset_path}}`
 
@@ -768,17 +751,17 @@ sections:
     instruction: Any additional context, design decisions, or implementation notes
     template: |
       **Implementation Notes:**
-      
+
       - {{note_1}}
       - {{note_2}}
-      
+
       **Design Decisions:**
-      
+
       - {{decision_1}}: {{rationale}}
       - {{decision_2}}: {{rationale}}
-      
+
       **Future Considerations:**
-      
+
       - {{future_enhancement_1}}
       - {{future_optimization_1}}
 ==================== END: .bmad-2d-unity-game-dev/templates/game-story-tmpl.yaml ====================