bmad-method 4.43.0 → 4.43.1

package/expansion-packs/bmad-godot-game-dev/data/elicitation-methods.md

@@ -0,0 +1,156 @@
+<!-- Powered by BMAD™ Core -->
+
+# Elicitation Methods Data
+
+## Core Reflective Methods
+
+**Expand or Contract for Audience**
+
+- Ask whether to 'expand' (add detail, elaborate) or 'contract' (simplify, clarify)
+- Identify specific target audience if relevant
+- Tailor content complexity and depth accordingly
+
+**Explain Reasoning (CoT Step-by-Step)**
+
+- Walk through the step-by-step thinking process
+- Reveal underlying assumptions and decision points
+- Show how conclusions were reached from current role's perspective
+
+**Critique and Refine**
+
+- Review output for flaws, inconsistencies, or improvement areas
+- Identify specific weaknesses from role's expertise
+- Suggest refined version reflecting domain knowledge
+
+## Structural Analysis Methods
+
+**Analyze Logical Flow and Dependencies**
+
+- Examine content structure for logical progression
+- Check internal consistency and coherence
+- Identify and validate dependencies between elements
+- Confirm effective ordering and sequencing
+
+**Assess Alignment with Overall Goals**
+
+- Evaluate content contribution to stated objectives
+- Identify any misalignments or gaps
+- Interpret alignment from specific role's perspective
+- Suggest adjustments to better serve goals
+
+## Risk and Challenge Methods
+
+**Identify Potential Risks and Unforeseen Issues**
+
+- Brainstorm potential risks from role's expertise
+- Identify overlooked edge cases or scenarios
+- Anticipate unintended consequences
+- Highlight implementation challenges
+
+**Challenge from Critical Perspective**
+
+- Adopt critical stance on current content
+- Play devil's advocate from specified viewpoint
+- Argue against proposal highlighting weaknesses
+- Apply YAGNI principles when appropriate (scope trimming)
+
+## Creative Exploration Methods
+
+**Tree of Thoughts Deep Dive**
+
+- Break problem into discrete "thoughts" or intermediate steps
+- Explore multiple reasoning paths simultaneously
+- Use self-evaluation to classify each path as "sure", "likely", or "impossible"
+- Apply search algorithms (BFS/DFS) to find optimal solution paths
+
+**Hindsight is 20/20: The 'If Only...' Reflection**
+
+- Imagine retrospective scenario based on current content
+- Identify the one "if only we had known/done X..." insight
+- Describe imagined consequences humorously or dramatically
+- Extract actionable learnings for current context
+
+## Multi-Persona Collaboration Methods
+
+**Agile Team Perspective Shift**
+
+- Rotate through different Scrum team member viewpoints
+- Product Owner: Focus on user value and business impact
+- Scrum Master: Examine process flow and team dynamics
+- Developer: Assess technical implementation and complexity
+- QA: Identify testing scenarios and quality concerns
+
+**Stakeholder Round Table**
+
+- Convene virtual meeting with multiple personas
+- Each persona contributes unique perspective on content
+- Identify conflicts and synergies between viewpoints
+- Synthesize insights into actionable recommendations
+
+**Meta-Prompting Analysis**
+
+- Step back to analyze the structure and logic of current approach
+- Question the format and methodology being used
+- Suggest alternative frameworks or mental models
+- Optimize the elicitation process itself
+
+## Advanced 2025 Techniques
+
+**Self-Consistency Validation**
+
+- Generate multiple reasoning paths for same problem
+- Compare consistency across different approaches
+- Identify most reliable and robust solution
+- Highlight areas where approaches diverge and why
+
+**ReWOO (Reasoning Without Observation)**
+
+- Separate parametric reasoning from tool-based actions
+- Create reasoning plan without external dependencies
+- Identify what can be solved through pure reasoning
+- Optimize for efficiency and reduced token usage
+
+**Persona-Pattern Hybrid**
+
+- Combine specific role expertise with elicitation pattern
+- Architect + Risk Analysis: Deep technical risk assessment
+- UX Expert + User Journey: End-to-end experience critique
+- PM + Stakeholder Analysis: Multi-perspective impact review
+
+**Emergent Collaboration Discovery**
+
+- Allow multiple perspectives to naturally emerge
+- Identify unexpected insights from persona interactions
+- Explore novel combinations of viewpoints
+- Capture serendipitous discoveries from multi-agent thinking
+
+## Game-Based Elicitation Methods
+
+**Red Team vs Blue Team**
+
+- Red Team: Attack the proposal, find vulnerabilities
+- Blue Team: Defend and strengthen the approach
+- Competitive analysis reveals blind spots
+- Results in more robust, battle-tested solutions
+
+**Innovation Tournament**
+
+- Pit multiple alternative approaches against each other
+- Score each approach across different criteria
+- Crowd-source evaluation from different personas
+- Identify winning combination of features
+
+**Escape Room Challenge**
+
+- Present content as constraints to work within
+- Find creative solutions within tight limitations
+- Identify minimum viable approach
+- Discover innovative workarounds and optimizations
+
+## Process Control
+
+**Proceed / No Further Actions**
+
+- Acknowledge choice to finalize current work
+- Accept output as-is or move to next step
+- Prepare to continue without additional elicitation

package/expansion-packs/bmad-godot-game-dev/data/technical-preferences.md

@@ -0,0 +1,3 @@
+# User-Defined Preferred Patterns and Preferences
+
+None Listed

package/expansion-packs/bmad-godot-game-dev/tasks/advanced-elicitation.md

@@ -0,0 +1,110 @@
+# Advanced Game Design Elicitation Task
+
+## Purpose
+
+- Provide optional reflective and brainstorming actions to enhance game design content quality
+- Enable deeper exploration of game mechanics and player experience through structured elicitation techniques
+- Support iterative refinement through multiple game development perspectives
+- Apply game-specific critical thinking to design decisions
+
+## Task Instructions
+
+### 1. Game Design Context and Review
+
+[[LLM: When invoked after outputting a game design section:
+
+1. First, provide a brief 1-2 sentence summary of what the user should look for in the section just presented, with game-specific focus (e.g., "Please review the core mechanics for player engagement and implementation feasibility. Pay special attention to how these mechanics create the intended player experience and whether they're technically achievable with Unity.")
+
+2. If the section contains game flow diagrams, level layouts, or system diagrams, explain each diagram briefly with game development context before offering elicitation options (e.g., "The gameplay loop diagram shows how player actions lead to rewards and progression. Notice how each step maintains player engagement and creates opportunities for skill development.")
+
+3. If the section contains multiple game elements (like multiple mechanics, multiple levels, multiple systems, etc.), inform the user they can apply elicitation actions to:
+   - The entire section as a whole
+   - Individual game elements within the section (specify which element when selecting an action)
+
+4. Then present the action list as specified below.]]
+
+### 2. Ask for Review and Present Game Design Action List
+
+[[LLM: Ask the user to review the drafted game design section. In the SAME message, inform them that they can suggest additions, removals, or modifications, OR they can select an action by number from the 'Advanced Game Design Elicitation & Brainstorming Actions'. If there are multiple game elements in the section, mention they can specify which element(s) to apply the action to. Then, present ONLY the numbered list (0-9) of these actions. Conclude by stating that selecting 9 will proceed to the next section. Await user selection. If an elicitation action (0-8) is chosen, execute it and then re-offer this combined review/elicitation choice. If option 9 is chosen, or if the user provides direct feedback, proceed accordingly.]]
+
+**Present the numbered list (0-9) with this exact format:**
+
+```text
+**Advanced Game Design Elicitation & Brainstorming Actions**
+Choose an action (0-9 - 9 to bypass - HELP for explanation of these options):
+
+0. Expand or Contract for Target Audience
+1. Explain Game Design Reasoning (Step-by-Step)
+2. Critique and Refine from Player Perspective
+3. Analyze Game Flow and Mechanic Dependencies
+4. Assess Alignment with Player Experience Goals
+5. Identify Potential Player Confusion and Design Risks
+6. Challenge from Critical Game Design Perspective
+7. Explore Alternative Game Design Approaches
+8. Hindsight Postmortem: The 'If Only...' Game Design Reflection
+9. Proceed / No Further Actions
+```
+
+### 2. Processing Guidelines
+
+**Do NOT show:**
+
+- The full protocol text with `[[LLM: ...]]` instructions
+- Detailed explanations of each option unless executing or the user asks, when giving the definition you can modify to tie its game development relevance
+- Any internal template markup
+
+**After user selection from the list:**
+
+- Execute the chosen action according to the game design protocol instructions below
+- Ask if they want to select another action or proceed with option 9 once complete
+- Continue until user selects option 9 or indicates completion
+
+## Game Design Action Definitions
+
+0. Expand or Contract for Target Audience
+   [[LLM: Ask the user whether they want to 'expand' on the game design content (add more detail, elaborate on mechanics, include more examples) or 'contract' it (simplify mechanics, focus on core features, reduce complexity). Also, ask if there's a specific player demographic or experience level they have in mind (casual players, hardcore gamers, children, etc.). Once clarified, perform the expansion or contraction from your current game design role's perspective, tailored to the specified player audience if provided.]]
+
+1. Explain Game Design Reasoning (Step-by-Step)
+   [[LLM: Explain the step-by-step game design thinking process that you used to arrive at the current proposal for this game content. Focus on player psychology, engagement mechanics, technical feasibility, and how design decisions support the overall player experience goals.]]
+
+2. Critique and Refine from Player Perspective
+   [[LLM: From your current game design role's perspective, review your last output or the current section for potential player confusion, engagement issues, balance problems, or areas for improvement. Consider how players will actually interact with and experience these systems, then suggest a refined version that better serves player enjoyment and understanding.]]
+
+3. Analyze Game Flow and Mechanic Dependencies
+   [[LLM: From your game design role's standpoint, examine the content's structure for logical gameplay progression, mechanic interdependencies, and player learning curve. Confirm if game elements are introduced in an effective order that teaches players naturally and maintains engagement throughout the experience.]]
+
+4. Assess Alignment with Player Experience Goals
+   [[LLM: Evaluate how well the current game design content contributes to the stated player experience goals and core game pillars. Consider whether the mechanics actually create the intended emotions and engagement patterns. Identify any misalignments between design intentions and likely player reactions.]]
+
+5. Identify Potential Player Confusion and Design Risks
+   [[LLM: Based on your game design expertise, brainstorm potential sources of player confusion, overlooked edge cases in gameplay, balance issues, technical implementation risks, or unintended player behaviors that could emerge from the current design. Consider both new and experienced players' perspectives.]]
+
+6. Challenge from Critical Game Design Perspective
+   [[LLM: Adopt a critical game design perspective on the current content. If the user specifies another viewpoint (e.g., 'as a casual player', 'as a speedrunner', 'as a mobile player', 'as a technical implementer'), critique the content from that specified perspective. If no other role is specified, play devil's advocate from your game design expertise, arguing against the current design proposal and highlighting potential weaknesses, player experience issues, or implementation challenges. This can include questioning scope creep, unnecessary complexity, or features that don't serve the core player experience.]]
+
+7. Explore Alternative Game Design Approaches
+   [[LLM: From your game design role's perspective, first broadly brainstorm a range of diverse approaches to achieving the same player experience goals or solving the same design challenge. Consider different genres, mechanics, interaction models, or technical approaches. Then, from this wider exploration, select and present 2-3 distinct alternative design approaches, detailing the pros, cons, player experience implications, and technical feasibility you foresee for each.]]
+
+8. Hindsight Postmortem: The 'If Only...' Game Design Reflection
+   [[LLM: In your current game design persona, imagine this is a postmortem for a shipped game based on the current design content. What's the one 'if only we had designed/considered/tested X...' that your role would highlight from a game design perspective? Include the imagined player reactions, review scores, or development consequences. This should be both insightful and somewhat humorous, focusing on common game design pitfalls.]]
+
+9. Proceed / No Further Actions
+   [[LLM: Acknowledge the user's choice to finalize the current game design work, accept the AI's last output as is, or move on to the next step without selecting another action from this list. Prepare to proceed accordingly.]]
+
+## Game Development Context Integration
+
+This elicitation task is specifically designed for game development and should be used in contexts where:
+
+- **Game Mechanics Design**: When defining core gameplay systems and player interactions
+- **Player Experience Planning**: When designing for specific emotional responses and engagement patterns
+- **Technical Game Architecture**: When balancing design ambitions with implementation realities
+- **Game Balance and Progression**: When designing difficulty curves and player advancement systems
+- **Platform Considerations**: When adapting designs for different devices and input methods
+
+The questions and perspectives offered should always consider:
+
+- Player psychology and motivation
+- Technical feasibility with Godot
+- Performance implications for stable frame rate targets
+- Cross-platform compatibility (PC, console, mobile)
+- Game development best practices and common pitfalls

package/expansion-packs/bmad-godot-game-dev/tasks/apply-qa-fixes.md

@@ -0,0 +1,224 @@
+<!-- Powered by BMAD™ Core -->
+
+# apply-qa-fixes
+
+Implement fixes based on QA results (gate and assessments) for a specific Godot game story. This task is for the Game Developer agent to systematically consume QA outputs and apply game code/test changes while only updating allowed sections in the story file.
+
+## Purpose
+
+- Read QA outputs for a game story (gate YAML + assessment markdowns)
+- Create a prioritized, deterministic fix plan for game features
+- Apply game code and test changes to close gaps and address issues
+- Update only the allowed story sections for the Game Developer agent
+
+## Inputs
+
+```yaml
+required:
+  - story_id: '{epic}.{story}' # e.g., "2.2"
+  - qa_root: from `.bmad-godot-game-dev/config.yaml` key `qa.qaLocation` (e.g., `docs/project/qa`)
+  - story_root: from `.bmad-godot-game-dev/config.yaml` key `devStoryLocation` (e.g., `docs/project/stories`)
+  - project_root: Godot project root directory (containing project.godot)
+
+optional:
+  - story_title: '{title}' # derive from story H1 if missing
+  - story_slug: '{slug}' # derive from title (lowercase, hyphenated) if missing
+```
+
+## QA Sources to Read
+
+- Gate (YAML): `{qa_root}/gates/{epic}.{story}-*.yml`
+  - If multiple, use the most recent by modified time
+- Assessments (Markdown):
+  - Test Design: `{qa_root}/assessments/{epic}.{story}-test-design-*.md`
+  - Traceability: `{qa_root}/assessments/{epic}.{story}-trace-*.md`
+  - Risk Profile: `{qa_root}/assessments/{epic}.{story}-risk-*.md`
+  - NFR Assessment: `{qa_root}/assessments/{epic}.{story}-nfr-*.md`
+
+## Prerequisites
+
+- Godot 4.x installed and configured
+- Testing frameworks installed:
+  - **GDScript**: GUT (Godot Unit Test) framework installed as addon
+  - **C#**: GoDotTest or GodotTestDriver NuGet packages installed
+- Project builds successfully in Godot Editor
+- Test commands available:
+  - GDScript: `godot --headless --script res://addons/gut/gut_cmdln.gd`
+  - C#: `dotnet test` or `godot --headless --run-tests`
+
+## Process (Do not skip steps)
+
+### 0) Load Core Config & Locate Story
+
+- Read `bmad-core/core-config.yaml` and resolve `qa_root`, `story_root`, and `project_root`
+- Locate story file in `{story_root}/{epic}.{story}.*.md`
+  - HALT if missing and ask for correct story id/path
+
+### 1) Collect QA Findings
+
+- Parse the latest gate YAML:
+  - `gate` (PASS|CONCERNS|FAIL|WAIVED)
+  - `top_issues[]` with `id`, `severity`, `finding`, `suggested_action`
+  - `nfr_validation.*.status` and notes
+  - `trace` coverage summary/gaps
+  - `test_design.coverage_gaps[]`
+  - `risk_summary.recommendations.must_fix[]` (if present)
+- Read any present assessment markdowns and extract explicit gaps/recommendations
+
+### 2) Build Deterministic Fix Plan (Priority Order)
+
+Apply in order, highest priority first:
+
+1. High severity items in `top_issues` (gameplay/performance/stability/maintainability)
+2. NFR statuses: all FAIL must be fixed → then CONCERNS
+3. Test Design `coverage_gaps` (prioritize P0 gameplay scenarios)
+4. Trace uncovered requirements (AC-level, especially gameplay mechanics)
+5. Risk `must_fix` recommendations
+6. Medium severity issues, then low
+
+Guidance:
+
+- Prefer tests closing coverage gaps before/with code changes
+- Keep changes minimal and targeted; follow Godot best practices and project architecture
+- Respect scene organization and node hierarchy
+- Follow GDScript style guide or C# conventions as appropriate
+
+### 3) Apply Changes
+
+- Implement game code fixes per plan:
+  - GDScript: Follow Godot style guide, use signals for decoupling
+  - C#: Follow .NET conventions, use events/delegates appropriately
+- Add missing tests to close coverage gaps:
+  - **GDScript Tests (GUT)**:
+    - Unit tests in `test/unit/` for game logic
+    - Integration tests in `test/integration/` for scene interactions
+    - Use `gut.p()` for parameterized tests
+    - Mock nodes with `double()` and `stub()`
+  - **C# Tests (GoDotTest/GodotTestDriver)**:
+    - Unit tests using xUnit or NUnit patterns
+    - Integration tests for scene and node interactions
+    - Use test fixtures for game state setup
+- Follow Godot patterns:
+  - Autoload/singleton patterns for global game state
+  - Signal-based communication between nodes
+  - Resource files (.tres/.res) for data management
+  - Scene inheritance for reusable components
+
+### 4) Validate
+
+**For GDScript Projects:**
+
+- Run GUT tests: `godot --headless --script res://addons/gut/gut_cmdln.gd -gselect=test/ -gexit`
+- Check for script errors in Godot Editor (Script Editor panel)
+- Validate scene references and node paths
+- Run game in editor to verify no runtime errors
+
+**For C# Projects:**
+
+- Build solution: `dotnet build`
+- Run tests: `dotnet test` or `godot --headless --run-tests`
+- Check for compilation errors
+- Validate no null reference exceptions in gameplay
+
+**For Both:**
+
+- Test gameplay mechanics manually if needed
+- Verify performance (check FPS, memory usage)
+- Iterate until all tests pass and no errors
+
+### 5) Update Story (Allowed Sections ONLY)
+
+CRITICAL: Dev agent is ONLY authorized to update these sections of the story file. Do not modify any other sections (e.g., QA Results, Story, Acceptance Criteria, Dev Notes, Testing):
+
+- Tasks / Subtasks Checkboxes (mark any fix subtask you added as done)
+- Dev Agent Record →
+  - Agent Model Used (if changed)
+  - Debug Log References (test results, Godot console output)
+  - Completion Notes List (what changed, why, how)
+  - File List (all added/modified/deleted files)
+- Change Log (new dated entry describing applied fixes)
+- Status (see Rule below)
+
+Status Rule:
+
+- If gate was PASS and all identified gaps are closed → set `Status: Ready for Done`
+- Otherwise → set `Status: Ready for Review` and notify QA to re-run the review
+
+### 6) Do NOT Edit Gate Files
+
+- Dev does not modify gate YAML. If fixes address issues, request QA to re-run `review-story` to update the gate
+
+## Blocking Conditions
+
+- Missing `bmad-core/core-config.yaml`
+- Story file not found for `story_id`
+- No QA artifacts found (neither gate nor assessments)
+  - HALT and request QA to generate at least a gate file (or proceed only with clear developer-provided fix list)
+- Godot project file (`project.godot`) not found
+- Testing framework not properly installed (GUT addon missing or NuGet packages not restored)
+
+## Completion Checklist
+
+- Godot project builds without errors
+- All tests pass:
+  - GDScript: GUT tests green
+  - C#: dotnet test successful
+- No script errors in Godot Editor
+- All high severity `top_issues` addressed
+- NFR FAIL → resolved; CONCERNS minimized or documented
+- Coverage gaps closed or explicitly documented with rationale
+- Gameplay features tested and working
+- Story updated (allowed sections only) including File List and Change Log
+- Status set according to Status Rule
+
+## Example: Story 2.2 - Player Movement System
+
+Given gate `docs/project/qa/gates/2.2-*.yml` shows
+
+- `coverage_gaps`: Jump mechanics edge cases untested (AC2)
+- `coverage_gaps`: Input buffering not tested (AC4)
+- `top_issues`: Performance drops when multiple players active
+
+Fix plan:
+
+**GDScript Example:**
+
+- Add GUT test for jump height variation based on button hold time
+- Add test for input buffering during state transitions
+- Optimize player movement script using object pooling for effects
+- Test with `gut.p()` parameterized tests for different player counts
+
+**C# Example:**
+
+- Add GoDotTest unit test for jump physics calculations
+- Add integration test for input system using GodotTestDriver
+- Refactor movement system to use Jobs/Tasks for parallel processing
+- Verify with performance profiler
+
+- Re-run tests and update Dev Agent Record + File List accordingly
+
+## Key Principles
+
+- Deterministic, risk-first prioritization
+- Minimal, maintainable changes following Godot best practices
+- Tests validate gameplay behavior and close gapså
+- Respect Godot's node-based architecture and signal system
+- Maintain clear separation between game logic and presentation
+- Strict adherence to allowed story update areas
+- Gate ownership remains with QA; Game Developer signals readiness via Status
+
+## Testing Framework References
+
+### GUT (GDScript)
+
+- Documentation: https://github.com/bitwes/Gut/wiki
+- Test structure: `extends GutTest`
+- Assertions: `assert_eq()`, `assert_true()`, `assert_has_signal()`
+- Mocking: `double()`, `stub()`, `spy_on()`
+
+### GoDotTest/GodotTestDriver (C#)
+
+- GoDotTest: xUnit-style testing for Godot C#
+- GodotTestDriver: Integration testing with scene manipulation
+- Test attributes: `[Fact]`, `[Theory]`, `[InlineData]`
+- Scene testing: Load scenes, interact with nodes, verify state

package/expansion-packs/bmad-godot-game-dev/tasks/brownfield-create-epic.md

@@ -0,0 +1,162 @@
+<!-- Powered by BMAD™ Core -->
+
+# Create Brownfield Epic Task
+
+## Purpose
+
+Create a single epic for smaller brownfield enhancements that don't require the full PRD and Architecture documentation process. This task is for isolated features or modifications that can be completed within a focused scope.
+
+## When to Use This Task
+
+**Use this task when:**
+
+- The enhancement can be completed in 1-3 stories
+- No significant architectural changes are required
+- The enhancement follows existing project patterns
+- Integration complexity is minimal
+- Risk to existing system is low
+
+**Use the full brownfield PRD/Architecture process when:**
+
+- The enhancement requires multiple coordinated stories
+- Architectural planning is needed
+- Significant integration work is required
+- Risk assessment and mitigation planning is necessary
+
+## Instructions
+
+### 1. Project Analysis (Required)
+
+Before creating the epic, gather essential information about the existing project:
+
+**Existing Project Context:**
+
+- [ ] Project purpose and current functionality understood
+- [ ] Existing technology stack identified
+- [ ] Current architecture patterns noted
+- [ ] Integration points with existing system identified
+
+**Enhancement Scope:**
+
+- [ ] Enhancement clearly defined and scoped
+- [ ] Impact on existing functionality assessed
+- [ ] Required integration points identified
+- [ ] Success criteria established
+
+### 2. Epic Creation
+
+Create a focused epic following this structure:
+
+#### Epic Title
+
+{{Enhancement Name}} - Brownfield Enhancement
+
+#### Epic Goal
+
+{{1-2 sentences describing what the epic will accomplish and why it adds value}}
+
+#### Epic Description
+
+**Existing System Context:**
+
+- Current relevant functionality: {{brief description}}
+- Technology stack: {{relevant existing technologies}}
+- Integration points: {{where new work connects to existing system}}
+
+**Enhancement Details:**
+
+- What's being added/changed: {{clear description}}
+- How it integrates: {{integration approach}}
+- Success criteria: {{measurable outcomes}}
+
+#### Stories
+
+List 1-3 focused stories that complete the epic:
+
+1. **Story 1:** {{Story title and brief description}}
+2. **Story 2:** {{Story title and brief description}}
+3. **Story 3:** {{Story title and brief description}}
+
+#### Compatibility Requirements
+
+- [ ] Existing APIs remain unchanged
+- [ ] Database schema changes are backward compatible
+- [ ] UI changes follow existing patterns
+- [ ] Performance impact is minimal
+
+#### Risk Mitigation
+
+- **Primary Risk:** {{main risk to existing system}}
+- **Mitigation:** {{how risk will be addressed}}
+- **Rollback Plan:** {{how to undo changes if needed}}
+
+#### Definition of Done
+
+- [ ] All stories completed with acceptance criteria met
+- [ ] Existing functionality verified through testing
+- [ ] Integration points working correctly
+- [ ] Documentation updated appropriately
+- [ ] No regression in existing features
+
+### 3. Validation Checklist
+
+Before finalizing the epic, ensure:
+
+**Scope Validation:**
+
+- [ ] Epic can be completed in 1-3 stories maximum
+- [ ] No architectural documentation is required
+- [ ] Enhancement follows existing patterns
+- [ ] Integration complexity is manageable
+
+**Risk Assessment:**
+
+- [ ] Risk to existing system is low
+- [ ] Rollback plan is feasible
+- [ ] Testing approach covers existing functionality
+- [ ] Team has sufficient knowledge of integration points
+
+**Completeness Check:**
+
+- [ ] Epic goal is clear and achievable
+- [ ] Stories are properly scoped
+- [ ] Success criteria are measurable
+- [ ] Dependencies are identified
+
+### 4. Handoff to Story Manager
+
+Once the epic is validated, provide this handoff to the Story Manager:
+
+---
+
+**Story Manager Handoff:**
+
+"Please develop detailed user stories for this brownfield epic. Key considerations:
+
+- This is an enhancement to an existing system running {{technology stack}}
+- Integration points: {{list key integration points}}
+- Existing patterns to follow: {{relevant existing patterns}}
+- Critical compatibility requirements: {{key requirements}}
+- Each story must include verification that existing functionality remains intact
+
+The epic should maintain system integrity while delivering {{epic goal}}."
+
+---
+
+## Success Criteria
+
+The epic creation is successful when:
+
+1. Enhancement scope is clearly defined and appropriately sized
+2. Integration approach respects existing system architecture
+3. Risk to existing functionality is minimized
+4. Stories are logically sequenced for safe implementation
+5. Compatibility requirements are clearly specified
+6. Rollback plan is feasible and documented
+
+## Important Notes
+
+- This task is specifically for SMALL brownfield enhancements
+- If the scope grows beyond 3 stories, consider the full brownfield PRD process
+- Always prioritize existing system integrity over new functionality
+- When in doubt about scope or complexity, escalate to full brownfield planning