bmad-method 4.43.0 → 4.43.1

package/expansion-packs/bmad-godot-game-dev/tasks/game-test-design.md

@@ -0,0 +1,219 @@
+<!-- Powered by BMAD™ Core -->
+
+# game-test-design
+
+Create comprehensive Godot game test scenarios using GUT (GDScript) or GoDotTest/GodotTestDriver (C#) with appropriate test level recommendations for game feature implementation.
+
+## Inputs
+
+```yaml
+required:
+  - story_id: '{epic}.{story}' # e.g., "1.3"
+  - story_path: '{devStoryLocation}/{epic}.{story}.*.md' # Path from core-config.yaml
+  - story_title: '{title}' # If missing, derive from story file H1
+  - story_slug: '{slug}' # If missing, derive from title (lowercase, hyphenated)
+```
+
+## Purpose
+
+Design a complete Godot game test strategy that identifies what to test, at which level (unit/integration/playtesting), and which testing framework to use (GUT for GDScript, GoDotTest/GodotTestDriver for C#). This ensures efficient test coverage for game mechanics, systems, and player experience while maintaining appropriate test boundaries.
+
+## Dependencies
+
+```yaml
+data:
+  - game-test-levels-framework.md # Unit/Integration/Playtesting decision criteria
+  - game-test-priorities-matrix.md # P0/P1/P2/P3 classification for game features
+frameworks:
+  gdscript:
+    - GUT (Godot Unit Test) # Native GDScript testing framework
+  csharp:
+    - GoDotTest # xUnit-based testing for C#
+    - GodotTestDriver # UI automation and integration testing
+```
+
+## Godot Testing Frameworks
+
+### GUT (Godot Unit Test) - GDScript
+
+- **Best for**: Game logic, state machines, inventory systems, damage calculations
+- **Setup**: Install via AssetLib or GitHub
+- **Test location**: `res://tests/unit/`
+- **Example**: Testing player health system, weapon damage modifiers
+
+### GoDotTest - C#
+
+- **Best for**: C# game systems, complex algorithms, data structures
+- **Setup**: NuGet package with xUnit integration
+- **Test location**: `tests/` directory in project root
+- **Example**: Testing procedural generation, AI decision trees
+
+### GodotTestDriver - C#
+
+- **Best for**: UI automation, integration testing, scene transitions
+- **Setup**: NuGet package for UI testing
+- **Test location**: `tests/integration/`
+- **Example**: Testing menu navigation, save/load flows, multiplayer lobbies
+
+## Process
+
+### 1. Analyze Story Requirements
+
+Break down each acceptance criterion into testable game scenarios. For each AC:
+
+- Identify the core game mechanic or system to test
+- Determine input variations (controls, player actions)
+- Consider edge cases (collision boundaries, resource limits)
+- Note platform-specific behaviors
+- Identify performance requirements (FPS, memory)
+
+### 2. Apply Game Test Level Framework
+
+**Reference:** Load `game-test-levels-framework.md` for detailed criteria
+
+Quick rules for Godot:
+
+- **Unit Tests (GUT/GoDotTest)**: Game logic, damage calculations, inventory systems, state machines
+- **Integration Tests (GUT/GodotTestDriver)**: Scene interactions, signal connections, save/load, physics
+- **Playtesting**: Full gameplay loops, difficulty balance, fun factor, performance on target hardware
+
+### 3. Assign Priorities
+
+**Reference:** Load `test-priorities-matrix.md` for classification
+
+Quick priority assignment for games:
+
+- **P0**: Game-breaking bugs, save corruption, core mechanics, progression blockers
+- **P1**: Combat systems, player movement, UI responsiveness, multiplayer sync
+- **P2**: Visual effects, audio, achievements, secondary mechanics
+- **P3**: Cosmetics, easter eggs, optional content
+
+### 4. Design Test Scenarios
+
+For each identified test need, create:
+
+```yaml
+test_scenario:
+  id: '{epic}.{story}-{LEVEL}-{SEQ}'
+  requirement: 'AC reference'
+  priority: P0|P1|P2|P3
+  level: unit|integration|playtest
+  framework: GUT|GoDotTest|GodotTestDriver|Manual
+  description: 'What game feature/mechanic is being tested'
+  justification: 'Why this level and framework were chosen'
+  test_scene: 'res://tests/{TestSceneName}.tscn' # For automated tests
+  mitigates_risks: ['PERF-001', 'GAME-002'] # From risk profile
+```
+
+### 5. Validate Coverage
+
+Ensure:
+
+- Every AC has at least one test
+- No duplicate coverage across levels
+- Critical paths have multiple levels
+- Risk mitigations are addressed
+
+## Outputs
+
+### Output 1: Test Design Document
+
+**Save to:** `qa.qaLocation/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md`
+
+```markdown
+# Test Design: Story {epic}.{story}
+
+Date: {date}
+Designer: Quinn (Game Test Architect)
+
+## Game Test Strategy Overview
+
+- Total test scenarios: X
+- Unit tests (GUT/GoDotTest): Y (A%)
+- Integration tests (GodotTestDriver): Z (B%)
+- Playtesting scenarios: W (C%)
+- Framework distribution: GUT: X%, GoDotTest: Y%, Manual: Z%
+- Priority distribution: P0: X, P1: Y, P2: Z
+
+## Test Scenarios by Acceptance Criteria
+
+### AC1: {description}
+
+#### Scenarios
+
+| ID           | Level       | Framework | Priority | Test                          | Justification                |
+| ------------ | ----------- | --------- | -------- | ----------------------------- | ---------------------------- |
+| 1.3-UNIT-001 | Unit        | GUT       | P0       | Player damage calculation     | Core combat logic            |
+| 1.3-INT-001  | Integration | GoDotTest | P0       | Enemy AI pathfinding          | NavigationAgent2D behavior   |
+| 1.3-PLAY-001 | Playtest    | Manual    | P1       | Boss fight difficulty balance | Player experience validation |
+
+[Continue for all ACs...]
+
+## Risk Coverage
+
+[Map test scenarios to identified risks if risk profile exists]
+
+## Recommended Execution Order
+
+1. P0 Unit tests (fail fast)
+2. P0 Integration tests
+3. P0 E2E tests
+4. P1 tests in order
+5. P2+ as time permits
+```
+
+### Output 2: Gate YAML Block
+
+Generate for inclusion in quality gate:
+
+```yaml
+test_design:
+  scenarios_total: X
+  by_level:
+    unit: Y
+    integration: Z
+    playtest: W
+  by_framework:
+    gut: A
+    godottest: B
+    testdriver: C
+    manual: D
+  by_priority:
+    p0: A
+    p1: B
+    p2: C
+  coverage_gaps: [] # List any ACs without tests
+  performance_tests: [] # FPS, memory, load time tests
+```
+
+### Output 3: Trace References
+
+Print for use by trace-requirements task:
+
+```text
+Test design matrix: qa.qaLocation/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md
+P0 tests identified: {count}
+```
+
+## Game Testing Quality Checklist
+
+Before finalizing, verify:
+
+- [ ] Every AC has test coverage
+- [ ] Test frameworks match language (GUT for GDScript, GoDotTest for C#)
+- [ ] Physics and collision tests use proper test scenes
+- [ ] Performance tests target minimum spec hardware
+- [ ] Multiplayer tests cover desync scenarios
+- [ ] Save/load tests verify data integrity
+- [ ] Platform-specific tests for each export target
+- [ ] Test scenes are properly organized in res://tests/
+
+## Key Game Testing Principles
+
+- **Shift left**: Test game logic early with GUT/GoDotTest before full integration
+- **Performance first**: Profile early and often, test on min spec
+- **Player experience**: Balance automated tests with human playtesting
+- **Framework selection**: GUT for GDScript game logic, GoDotTest for C# systems, GodotTestDriver for UI
+- **Scene isolation**: Test components in minimal scenes to reduce dependencies
+- **Fast feedback**: Unit tests in CI/CD, integration tests nightly, playtests per sprint
+- **Platform coverage**: Test exports on all target platforms regularly

package/expansion-packs/bmad-godot-game-dev/tasks/generate-ai-frontend-prompt.md

@@ -0,0 +1,51 @@
+# Create AI Frontend Prompt Task
+
+## Purpose
+
+To generate a masterful, comprehensive, and optimized prompt that can be used with any AI-driven frontend development tool (e.g., Vercel v0, Lovable.ai, or similar) to scaffold or generate significant portions of a frontend application.
+
+## Inputs
+
+- Completed UI/UX Specification (`front-end-spec.md`)
+- Completed Frontend Architecture Document (`front-end-architecture`) or a full stack combined architecture such as `architecture.md`
+- Main System Architecture Document (`architecture` - for API contracts and tech stack to give further context)
+
+## Key Activities & Instructions
+
+### 1. Core Prompting Principles
+
+Before generating the prompt, you must understand these core principles for interacting with a generative AI for code.
+
+- **Be Explicit and Detailed**: The AI cannot read your mind. Provide as much detail and context as possible. Vague requests lead to generic or incorrect outputs.
+- **Iterate, Don't Expect Perfection**: Generating an entire complex application in one go is rare. The most effective method is to prompt for one component or one section at a time, then build upon the results.
+- **Provide Context First**: Always start by providing the AI with the necessary context, such as the tech stack, existing code snippets, and overall project goals.
+- **Mobile-First Approach**: Frame all UI generation requests with a mobile-first design mindset. Describe the mobile layout first, then provide separate instructions for how it should adapt for tablet and desktop.
+
+### 2. The Structured Prompting Framework
+
+To ensure the highest quality output, you MUST structure every prompt using the following four-part framework.
+
+1. **High-Level Goal**: Start with a clear, concise summary of the overall objective. This orients the AI on the primary task.
+   - _Example: "Create a responsive user registration form with client-side validation and API integration."_
+2. **Detailed, Step-by-Step Instructions**: Provide a granular, numbered list of actions the AI should take. Break down complex tasks into smaller, sequential steps. This is the most critical part of the prompt.
+   - _Example: "1. Create a new file named `RegistrationForm.js`. 2. Use React hooks for state management. 3. Add styled input fields for 'Name', 'Email', and 'Password'. 4. For the email field, ensure it is a valid email format. 5. On submission, call the API endpoint defined below."_
+3. **Code Examples, Data Structures & Constraints**: Include any relevant snippets of existing code, data structures, or API contracts. This gives the AI concrete examples to work with. Crucially, you must also state what _not_ to do.
+   - _Example: "Use this API endpoint: `POST /api/register`. The expected JSON payload is `{ "name": "string", "email": "string", "password": "string" }`. Do NOT include a 'confirm password' field. Use Tailwind CSS for all styling."_
+4. **Define a Strict Scope**: Explicitly define the boundaries of the task. Tell the AI which files it can modify and, more importantly, which files to leave untouched to prevent unintended changes across the codebase.
+   - _Example: "You should only create the `RegistrationForm.js` component and add it to the `pages/register.js` file. Do NOT alter the `Navbar.js` component or any other existing page or component."_
+
+### 3. Assembling the Master Prompt
+
+You will now synthesize the inputs and the above principles into a final, comprehensive prompt.
+
+1. **Gather Foundational Context**:
+   - Start the prompt with a preamble describing the overall project purpose, the full tech stack (e.g., Next.js, TypeScript, Tailwind CSS), and the primary UI component library being used.
+2. **Describe the Visuals**:
+   - If the user has design files (Figma, etc.), instruct them to provide links or screenshots.
+   - If not, describe the visual style: color palette, typography, spacing, and overall aesthetic (e.g., "minimalist", "corporate", "playful").
+3. **Build the Prompt using the Structured Framework**:
+   - Follow the four-part framework from Section 2 to build out the core request, whether it's for a single component or a full page.
+4. **Present and Refine**:
+   - Output the complete, generated prompt in a clear, copy-pasteable format (e.g., a large code block).
+   - Explain the structure of the prompt and why certain information was included, referencing the principles above.
+   - <important_note>Conclude by reminding the user that all AI-generated code will require careful human review, testing, and refinement to be considered production-ready.</important_note>

package/expansion-packs/bmad-godot-game-dev/tasks/kb-mode-interaction.md

@@ -0,0 +1,77 @@
+<!-- Powered by BMAD™ Core -->
+
+# KB Mode Interaction Task
+
+## Purpose
+
+Provide a user-friendly interface to the BMad knowledge base without overwhelming users with information upfront.
+
+## Instructions
+
+When entering KB mode (\*kb-mode), follow these steps:
+
+### 1. Welcome and Guide
+
+Announce entering KB mode with a brief, friendly introduction.
+
+### 2. Present Topic Areas
+
+Offer a concise list of main topic areas the user might want to explore:
+
+**What would you like to know more about?**
+
+1. **Setup & Installation** - Getting started with BMad
+2. **Workflows** - Choosing the right workflow for your project
+3. **Web vs IDE** - When to use each environment
+4. **Agents** - Understanding specialized agents and their roles
+5. **Documents** - PRDs, Architecture, Stories, and more
+6. **Agile Process** - How BMad implements Agile methodologies
+7. **Configuration** - Customizing BMad for your needs
+8. **Best Practices** - Tips for effective BMad usage
+
+Or ask me about anything else related to BMad-Method!
+
+### 3. Respond Contextually
+
+- Wait for user's specific question or topic selection
+- Provide focused, relevant information from the knowledge base
+- Offer to dive deeper or explore related topics
+- Keep responses concise unless user asks for detailed explanations
+
+### 4. Interactive Exploration
+
+- After answering, suggest related topics they might find helpful
+- Maintain conversational flow rather than data dumping
+- Use examples when appropriate
+- Reference specific documentation sections when relevant
+
+### 5. Exit Gracefully
+
+When user is done or wants to exit KB mode:
+
+- Summarize key points discussed if helpful
+- Remind them they can return to KB mode anytime with \*kb-mode
+- Suggest next steps based on what was discussed
+
+## Example Interaction
+
+**User**: \*kb-mode
+
+**Assistant**: I've entered KB mode and have access to the full BMad knowledge base. I can help you with detailed information about any aspect of BMad-Method.
+
+**What would you like to know more about?**
+
+1. **Setup & Installation** - Getting started with BMad
+2. **Workflows** - Choosing the right workflow for your project
+3. **Web vs IDE** - When to use each environment
+4. **Agents** - Understanding specialized agents and their roles
+5. **Documents** - PRDs, Architecture, Stories, and more
+6. **Agile Process** - How BMad implements Agile methodologies
+7. **Configuration** - Customizing BMad for your needs
+8. **Best Practices** - Tips for effective BMad usage
+
+Or ask me about anything else related to BMad-Method!
+
+**User**: Tell me about workflows
+
+**Assistant**: [Provides focused information about workflows from the KB, then offers to explore specific workflow types or related topics]