Merge d05f44fa62 into 21123d6349
This commit is contained in:
commit
379811f64d
|
|
@ -12,6 +12,8 @@
|
|||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- 💬 FOCUS on strategic scope decisions that keep projects viable
|
||||
- 🎯 EMPHASIZE lean MVP thinking while preserving long-term vision
|
||||
- ⚠️ NEVER de-scope, defer, or phase out requirements that the user explicitly included in their input documents without asking first
|
||||
- ⚠️ NEVER invent phasing (MVP/Growth/Vision) unless the user requests phased delivery — if input documents define all components as core requirements, they are ALL in scope
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
||||
|
||||
|
|
@ -75,10 +77,23 @@ Use structured decision-making for scope:
|
|||
- Advanced functionality that builds on MVP
|
||||
- Ask what features could be added in versions 2, 3, etc.
|
||||
|
||||
**⚠️ SCOPE CHANGE CONFIRMATION GATE:**
|
||||
- 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
|
||||
- Frame it as a recommendation, not a decision: "I'd recommend deferring X because [reason]. Do you agree, or should it stay in scope?"
|
||||
- NEVER silently move user requirements to a later phase or exclude them from MVP
|
||||
|
||||
### 4. Progressive Feature Roadmap
|
||||
|
||||
Create phased development approach:
|
||||
- Guide mapping of features across development phases
|
||||
**CRITICAL: Phasing is NOT automatic. Check the user's input first.**
|
||||
|
||||
Before proposing any phased approach, review the user's input documents:
|
||||
|
||||
- **If the input documents define all components as core requirements with no mention of phases:** Present all requirements as a single release scope. Do NOT invent phases or move requirements to fabricated future phases.
|
||||
- **If the input documents explicitly request phased delivery:** Guide mapping of features across the phases the user defined.
|
||||
- **If scope is unclear:** ASK the user whether they want phased delivery or a single release before proceeding.
|
||||
|
||||
**When the user wants phased delivery**, guide mapping of features across development phases:
|
||||
|
||||
- Structure as Phase 1 (MVP), Phase 2 (Growth), Phase 3 (Vision)
|
||||
- Ensure clear progression and dependencies
|
||||
|
||||
|
|
@ -98,6 +113,12 @@ Create phased development approach:
|
|||
- Platform features
|
||||
- New markets or use cases
|
||||
|
||||
**When the user wants a single release**, define the complete scope:
|
||||
|
||||
- All user-specified requirements are in scope
|
||||
- Focus must-have vs nice-to-have analysis on what ships in this release
|
||||
- Do NOT create phases — use must-have/nice-to-have priority within the single release
|
||||
|
||||
**Where does your current vision fit in this development sequence?**"
|
||||
|
||||
### 5. Risk-Based Scoping
|
||||
|
|
@ -129,6 +150,8 @@ Prepare comprehensive scoping section:
|
|||
|
||||
#### Content Structure:
|
||||
|
||||
**If user chose phased delivery:**
|
||||
|
||||
```markdown
|
||||
## Project Scoping & Phased Development
|
||||
|
||||
|
|
@ -160,6 +183,34 @@ Prepare comprehensive scoping section:
|
|||
**Resource Risks:** {{contingency_approach}}
|
||||
```
|
||||
|
||||
**If user chose single release (no phasing):**
|
||||
|
||||
```markdown
|
||||
## Project Scoping
|
||||
|
||||
### Strategy & Philosophy
|
||||
|
||||
**Approach:** {{chosen_approach}}
|
||||
**Resource Requirements:** {{team_size_and_skills}}
|
||||
|
||||
### Complete Feature Set
|
||||
|
||||
**Core User Journeys Supported:**
|
||||
{{all_journeys}}
|
||||
|
||||
**Must-Have Capabilities:**
|
||||
{{list_of_must_have_features}}
|
||||
|
||||
**Nice-to-Have Capabilities:**
|
||||
{{list_of_nice_to_have_features}}
|
||||
|
||||
### Risk Mitigation Strategy
|
||||
|
||||
**Technical Risks:** {{mitigation_approach}}
|
||||
**Market Risks:** {{validation_approach}}
|
||||
**Resource Risks:** {{contingency_approach}}
|
||||
```
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Present the scoping decisions for review, then display menu:
|
||||
|
|
@ -189,8 +240,9 @@ When user selects 'C', append the content directly to the document using the str
|
|||
|
||||
✅ Complete PRD document analyzed for scope implications
|
||||
✅ Strategic MVP approach defined and justified
|
||||
✅ Clear MVP feature boundaries established
|
||||
✅ Phased development roadmap created
|
||||
✅ Clear feature boundaries established (phased or single-release, per user preference)
|
||||
✅ All user-specified requirements accounted for — none silently removed or deferred
|
||||
✅ Any scope reduction recommendations presented to user with rationale and explicit confirmation obtained
|
||||
✅ Key risks identified and mitigation strategies defined
|
||||
✅ User explicitly agrees to scope decisions
|
||||
✅ A/P/C menu presented and handled correctly
|
||||
|
|
@ -202,8 +254,10 @@ When user selects 'C', append the content directly to the document using the str
|
|||
❌ Making scope decisions without strategic rationale
|
||||
❌ Not getting explicit user agreement on MVP boundaries
|
||||
❌ Missing critical risk analysis
|
||||
❌ Not creating clear phased development approach
|
||||
❌ Not presenting A/P/C menu after content generation
|
||||
❌ **CRITICAL**: Silently de-scoping or deferring requirements that the user explicitly included in their input documents
|
||||
❌ **CRITICAL**: Inventing phasing (MVP/Growth/Vision) when the user did not request phased delivery
|
||||
❌ **CRITICAL**: Making consequential scoping decisions (what is in/out of scope) without explicit user confirmation
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
|
|
|
|||
|
|
@ -138,7 +138,7 @@ Make targeted improvements:
|
|||
- All user success criteria
|
||||
- All functional requirements (capability contract)
|
||||
- All user journey narratives
|
||||
- All scope decisions (MVP, Growth, Vision)
|
||||
- All scope decisions (whether phased or single-release)
|
||||
- All non-functional requirements
|
||||
- Product differentiator and vision
|
||||
- Domain-specific requirements
|
||||
|
|
|
|||
Loading…
Reference in New Issue