5.2 KiB
5.2 KiB
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.