bi-agents/_bmad/wds/workflows/5-agentic-development/steps-e/step-01-scope-change.md

name, description, nextStepFile

name	description	nextStepFile
step-01-scope-change	Define exactly what is new, what is modified, and what must remain untouched	./step-02-analyze-impact.md

Step 1: Scope Change

STEP GOAL:

Define exactly what is new, what is modified, and what must remain untouched.

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 defining scope: new functionality, existing unchanged functionality, boundary map, and integration points
• 🚫 FORBIDDEN to begin analyzing impact or planning implementation — those are later steps
• 💬 Approach: Help user categorize all affected areas into new/modified/untouched
• 📋 Every integration point must be identified and documented

EXECUTION PROTOCOLS:

• 🎯 Produce a clear boundary map categorizing all areas as new, modified, or untouched
• 💾 Update dialog file with scope definition, boundary map, and integration points
• 📖 Reference the feature spec or change request
• 🚫 Do not analyze dependencies or plan implementation yet

CONTEXT BOUNDARIES:

• Available context: Feature specification or change request
• Focus: Scoping what changes and what stays the same
• Limits: No impact analysis, no implementation planning
• Dependencies: A feature spec or change request must exist

Sequence of Instructions (Do not deviate, skip, or optimize)

1. Load Feature Spec

• Read the feature specification or change request
• Understand the desired outcome from the user's perspective
• Clarify any ambiguities before proceeding

2. List All New Functionality

• Enumerate every new capability being added
• For each item: what it does, where it lives, how the user interacts with it
• Note any new UI components, API endpoints, data models, or routes

3. List All Existing Functionality That Must Stay Unchanged

• Identify every existing feature that is in scope or adjacent
• Explicitly state: "This must continue to work exactly as it does now"
• Include both direct features and indirect dependencies (e.g., shared components)

4. Create Boundary Map

Categorize all affected areas:

Category	Description	Examples
New	Does not exist yet, being added	New page, new API endpoint, new component
Modified	Exists and will be changed	Updated component to accept new props, extended API response
Untouched	Exists and must not change	Existing pages, unrelated features, shared utilities

5. Identify Integration Points

• Where does new code connect to existing code?
• What interfaces, APIs, or data structures are shared?
• Are there shared components that need to support both old and new behavior?
• Document each integration point and its risk level

6. Verify Checklist

• Feature spec loaded and understood
• New functionality listed
• Existing functionality that must stay unchanged listed
• Boundary map created (new / modified / untouched)
• Integration points identified
• Dialog file updated with scope definition

7. Present MENU OPTIONS

Display: "Select an Option: [C] Continue to Step 2: Analyze Impact"

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 scope is fully defined with boundary map and integration points will you then load and read fully {nextStepFile} to execute.

---

🚨 SYSTEM SUCCESS/FAILURE METRICS

✅ SUCCESS:

• Feature spec loaded and understood
• New functionality listed
• Existing functionality that must stay unchanged listed
• Boundary map created (new / modified / untouched)
• Integration points identified
• Dialog file updated with scope definition

❌ SYSTEM FAILURE:

• Beginning impact analysis before scope is defined
• Not identifying what must remain untouched
• Skipping integration point identification
• Leaving ambiguities in the feature spec unresolved

Master Rule: Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.