initial commit

_bmad/wds/workflows/5-agentic-development/steps-e/step-02-analyze-impact.md

@@ -0,0 +1,136 @@
+---
+name: 'step-02-analyze-impact'
+description: 'Understand how the proposed changes affect existing code and identify risks'
+
+# File References
+nextStepFile: './step-03-plan-implementation.md'
+---
+
+# Step 2: Analyze Impact
+
+## STEP GOAL:
+
+Understand how the proposed changes affect existing code, and identify risks.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are an Implementation Partner guiding structured development activities
+- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring software development methodology expertise, user brings domain knowledge and codebase familiarity
+- ✅ Maintain clear and structured tone throughout
+
+### Step-Specific Rules:
+
+- 🎯 Focus only on reading affected code, mapping dependencies, identifying breaking change risks, and assessing database/API impacts
+- 🚫 FORBIDDEN to begin planning or implementing changes — that is a later step
+- 💬 Approach: Deep dive into affected code with user, mapping what depends on what
+- 📋 Document a risk assessment table with likelihood, impact, and mitigation
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Produce a dependency map, breaking change risk list, and risk assessment
+- 💾 Document risk assessment in the dialog file
+- 📖 Reference the boundary map and integration points from Step 1
+- 🚫 Do not plan implementation order or write any code
+
+## CONTEXT BOUNDARIES:
+
+- Available context: Scope definition, boundary map, and integration points from Step 1
+- Focus: Impact analysis — dependencies, risks, breaking changes
+- Limits: No implementation planning, no code changes
+- Dependencies: Step 1 must be complete (scope defined)
+
+## Sequence of Instructions (Do not deviate, skip, or optimize)
+
+### 1. Read Code for All Affected Areas
+
+- Open and read every file identified as "modified" in the boundary map
+- Read files adjacent to integration points
+- Understand the current behavior before planning changes
+
+### 2. Map Dependencies
+
+- For each modified file, identify:
+  - What imports it / calls it / depends on it
+  - What it imports / calls / depends on
+- Build a dependency graph (mental or documented) of the affected area
+- Flag shared utilities, components, or state that multiple features rely on
+
+### 3. Identify Breaking Change Risks
+
+- Will any existing interface signatures change?
+- Will any existing data shapes change?
+- Could new code paths affect timing or ordering of existing operations?
+- Are there implicit assumptions in existing code that the new feature violates?
+
+### 4. Assess Database/API Impacts
+
+- Are database schema changes needed? (migrations, new tables, altered columns)
+- Are API contract changes needed? (new endpoints, changed response shapes)
+- Can changes be additive (non-breaking) or do they require migration?
+- Will existing clients (other services, mobile apps) be affected?
+
+### 5. Document What Could Go Wrong
+
+Write a risk assessment in the dialog file:
+
+| Risk | Likelihood | Impact | Mitigation |
+|------|-----------|--------|------------|
+| Shared component breaks for existing use | Medium | High | Test all existing consumers |
+| API change breaks mobile client | Low | High | Make change additive, not breaking |
+| State management conflict | Medium | Medium | Isolate new state, feature flag |
+
+### 6. Verify Checklist
+
+- [ ] All affected code read and understood
+- [ ] Dependencies mapped
+- [ ] Breaking change risks identified
+- [ ] Database/API impacts assessed
+- [ ] Risk assessment documented in dialog file
+
+### 7. Present MENU OPTIONS
+
+Display: "**Select an Option:** [C] Continue to Step 3: Plan Implementation"
+
+#### Menu Handling Logic:
+- IF C: Update design log, then load, read entire file, then execute {nextStepFile}
+- IF Any other comments or queries: help user respond then [Redisplay Menu Options]
+
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- User can chat or ask questions - always respond and then redisplay menu options
+
+## CRITICAL STEP COMPLETION NOTE
+
+ONLY WHEN the impact analysis is complete with dependencies mapped and risks documented will you then load and read fully `{nextStepFile}` to execute.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+- All affected code read and understood
+- Dependencies mapped
+- Breaking change risks identified
+- Database/API impacts assessed
+- Risk assessment documented in dialog file
+
+### ❌ SYSTEM FAILURE:
+- Beginning implementation planning without completing impact analysis
+- Not reading all affected code
+- Skipping dependency mapping
+- Not documenting risks
+
+**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.