Skip to content

Commit 36f9df6

Browse files
committed
fix: address CodeRabbit review feedback for PRD scoping step
step-08-scoping.md: - Neutral title replacing hard-coded "MVP & Future Features" - Task statement no longer mandates phase-based prioritization - Confirmation gate now covers artifact creation, not just de-scoping - Phased delivery uses user-defined phase labels/count instead of fixed 3 - "wants phased" phrasing replaced with "requests/chooses" - Development sequence question branches by release mode - Menu text conditional on delivery mode (no "phased roadmap" for single-release) - Handoff to step-09 now persists releaseMode in frontmatter - New failure mode for unapproved phase artifact creation step-11-polish.md: - Preservation rule now includes consent-critical evidence from step 8
1 parent 4655bb1 commit 36f9df6

File tree

2 files changed

+17
-24
lines changed

2 files changed

+17
-24
lines changed

src/bmm-skills/2-plan-workflows/bmad-create-prd/steps-c/step-08-scoping.md

Lines changed: 16 additions & 23 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
# Step 8: Scoping Exercise - MVP & Future Features
1+
# Step 8: Scoping Exercise - Scope Definition (Phased or Single-Release)
22

33
**Progress: Step 8 of 11** - Next: Functional Requirements
44

@@ -36,7 +36,7 @@
3636

3737
## YOUR TASK:
3838

39-
Conduct comprehensive scoping exercise to define MVP boundaries and prioritize features across development phases.
39+
Conduct comprehensive scoping exercise to define release boundaries and prioritize features based on the user's chosen delivery mode (phased or single-release).
4040

4141
## SCOPING SEQUENCE:
4242

@@ -81,6 +81,7 @@ Use structured decision-making for scope:
8181
- If you believe any user-specified requirement should be deferred or de-scoped, you MUST present this to the user and get explicit confirmation BEFORE removing it from scope
8282
- Frame it as a recommendation, not a decision: "I'd recommend deferring X because [reason]. Do you agree, or should it stay in scope?"
8383
- NEVER silently move user requirements to a later phase or exclude them from MVP
84+
- Before creating any consequential phase-based artifacts (e.g., phase tags, labels, or follow-on prompts), present artifact creation as a recommendation and proceed only after explicit user approval
8485

8586
### 4. Progressive Feature Roadmap
8687

@@ -92,34 +93,25 @@ Before proposing any phased approach, review the user's input documents:
9293
- **If the input documents explicitly request phased delivery:** Guide mapping of features across the phases the user defined.
9394
- **If scope is unclear:** ASK the user whether they want phased delivery or a single release before proceeding.
9495

95-
**When the user wants phased delivery**, guide mapping of features across development phases:
96+
**When the user requests phased delivery**, guide mapping of features across the phases the user defines:
9697

97-
- Structure as Phase 1 (MVP), Phase 2 (Growth), Phase 3 (Vision)
98-
- Ensure clear progression and dependencies
98+
- Use user-provided phase labels and count; if none are provided, propose a default (e.g., MVP/Growth/Vision) and ask for confirmation
99+
- Ensure clear progression and dependencies between phases
99100

100-
- Core user value delivery
101-
- Essential user journeys
102-
- Basic functionality that works reliably
101+
**Each phase should address:**
103102

104-
**Phase 2: Growth**
103+
- Core user value delivery and essential journeys for that phase
104+
- Clear boundaries on what ships in each phase
105+
- Dependencies on prior phases
105106

106-
- Additional user types
107-
- Enhanced features
108-
- Scale improvements
109-
110-
**Phase 3: Expansion**
111-
112-
- Advanced capabilities
113-
- Platform features
114-
- New markets or use cases
115-
116-
**When the user wants a single release**, define the complete scope:
107+
**When the user chooses a single release**, define the complete scope:
117108

118109
- All user-specified requirements are in scope
119110
- Focus must-have vs nice-to-have analysis on what ships in this release
120111
- Do NOT create phases — use must-have/nice-to-have priority within the single release
121112

122-
**Where does your current vision fit in this development sequence?**"
113+
**If phased delivery:** "Where does your current vision fit in this development sequence?"
114+
**If single release:** "How does your current vision map to this upcoming release?"
123115

124116
### 5. Risk-Based Scoping
125117

@@ -215,7 +207,7 @@ Prepare comprehensive scoping section:
215207

216208
Present the scoping decisions for review, then display menu:
217209
- Show strategic scoping plan (using structure from step 6)
218-
- Highlight MVP boundaries and phased roadmap
210+
- Highlight release boundaries and prioritization (phased roadmap only if phased delivery was selected)
219211
- Ask if they'd like to refine further, get other perspectives, or proceed
220212
- Present menu options naturally as part of conversation
221213

@@ -224,7 +216,7 @@ Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Fu
224216
#### Menu Handling Logic:
225217
- IF A: Invoke the `bmad-advanced-elicitation` skill with the current scoping analysis, process the enhanced insights that come back, ask user if they accept the improvements, if yes update content then redisplay menu, if no keep original content then redisplay menu
226218
- IF P: Invoke the `bmad-party-mode` skill with the scoping context, process the collaborative insights on MVP and roadmap decisions, ask user if they accept the changes, if yes update content then redisplay menu, if no keep original content then redisplay menu
227-
- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: ./step-09-functional.md
219+
- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array (also add `releaseMode: phased` or `releaseMode: single-release` to frontmatter based on user's choice), then read fully and follow: ./step-09-functional.md
228220
- IF Any other: help user respond, then redisplay menu
229221

230222
#### EXECUTION RULES:
@@ -258,6 +250,7 @@ When user selects 'C', append the content directly to the document using the str
258250
**CRITICAL**: Silently de-scoping or deferring requirements that the user explicitly included in their input documents
259251
**CRITICAL**: Inventing phasing (MVP/Growth/Vision) when the user did not request phased delivery
260252
**CRITICAL**: Making consequential scoping decisions (what is in/out of scope) without explicit user confirmation
253+
**CRITICAL**: Creating phase-based artifacts (tags, labels, follow-on prompts) without explicit user approval
261254

262255
**CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
263256
**CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file

src/bmm-skills/2-plan-workflows/bmad-create-prd/steps-c/step-11-polish.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -138,7 +138,7 @@ Make targeted improvements:
138138
- All user success criteria
139139
- All functional requirements (capability contract)
140140
- All user journey narratives
141-
- All scope decisions (whether phased or single-release)
141+
- All scope decisions (whether phased or single-release), including consent-critical evidence (explicit user confirmations and rationales for any scope changes from step 8)
142142
- All non-functional requirements
143143
- Product differentiator and vision
144144
- Domain-specific requirements

0 commit comments

Comments
 (0)