refactor: consolidate checklists and improve scope creep detection

- Remove duplicate checklists (epic-readiness, story-approval) in favor of bmad-core equivalents
- Add SCOPE-CREEP classification category to prevent scope expansion during reviews
- Change consolidation responsibility from architect to scrum master for better neutrality
- Update dependencies to include pm-checklist.md from core
- Maintain focus on original MVP scope through strict acceptance criteria compliance

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

expansion-packs/story-implementation/README.md

@@ -46,8 +46,10 @@ Addresses the complexity gap in agile story implementation by providing:
 - **epic-party-mode-retrospective.md**: Automatic epic retrospective with multi-agent analysis
 
 ### Checklists
-- **story-approval-checklist.md**: Product Owner story validation framework
+- Uses bmad-core checklists via execute-checklist task:
-- **epic-readiness-checklist.md**: Epic business readiness validation
+  - **po-master-checklist.md**: Epic readiness and business validation
+  - **pm-checklist.md**: Story approval and acceptance criteria validation
+  - **story-draft-checklist.md**: Story quality validation
 
 ## Integration with Core BMAD
 

expansion-packs/story-implementation/checklists/epic-readiness-checklist.md

@@ -1,64 +0,0 @@
-# epic-readiness-checklist.md
-
-**Purpose**: Validate epic business readiness and dependencies before story creation
-**Agent**: po (Product Owner)
-**Phase**: Pre-Story Creation Validation
-
-## Epic Business Readiness Validation
-
-### Epic Existence & Status Verification
-- [ ] **Epic file exists**: Epic file located in `docs/prd/epic-{epic_number}-*.md` or `docs/epics/epic-{epic_number}-*.md` or user-specified location confirmed
-- [ ] **Epic status approved**: Epic status is "Approved" (not Draft/In Progress/Review)
-- [ ] **Epic completion readiness**: Epic has clear business objectives and scope defined
-- [ ] **Epic format compliance**: Epic follows project template and documentation standards
-
-### Epic Dependencies Assessment
-- [ ] **Prerequisite epics completed**: All prerequisite epics are marked "Done" or dependencies resolved
-- [ ] **No blocking dependencies**: No unresolved technical or business blockers identified for epic scope
-- [ ] **Resource availability**: Required team members and resources available for epic execution
-- [ ] **External dependencies clear**: Third-party services, APIs, or integrations ready if needed
-
-### Epic Context Sufficiency Analysis
-- [ ] **Business goals clarity**: Epic provides sufficient context for meaningful story creation
-- [ ] **User journeys defined**: Business goals and user workflows are clearly articulated
-- [ ] **Success criteria specified**: Epic completion criteria and definition of done are explicit
-- [ ] **Acceptance boundaries**: Epic scope boundaries and out-of-scope items are clearly defined
-
-### Story Creation Readiness
-- [ ] **Story numbering valid**: Requested story number does not conflict with existing stories
-- [ ] **Epic sequence logic**: Story fits logical sequence within epic roadmap and dependencies
-- [ ] **Story prerequisites met**: All prerequisite stories for requested story are completed
-- [ ] **Business context sufficient**: Epic provides enough detail for comprehensive story definition
-
-### Business Value Validation
-- [ ] **Value proposition clear**: Epic business value and ROI rationale are explicitly documented
-- [ ] **Priority alignment**: Epic aligns with current business priorities and strategic objectives
-- [ ] **Stakeholder alignment**: Key stakeholders have reviewed and approved epic scope
-- [ ] **Risk assessment complete**: Known risks and mitigation strategies are documented
-
-## Validation Outcomes
-
-### If ALL checks pass:
-- **Status**: Epic ready for story creation
-- **Action**: Proceed with create_story workflow step
-- **Documentation**: Update story file with epic validation timestamp and PO approval
-
-### If ANY check fails:
-- **Status**: Epic not ready for story creation
-- **Action**: HALT workflow and address identified issues
-- **Escalation**: Work with SM and stakeholders to resolve epic readiness blockers
-- **Documentation**: Document specific issues and required remediation steps
-
-## Notes
-
-- This checklist must be completed before any story creation begins
-- Focus on business readiness rather than technical implementation details
-- Epic validation ensures stories are created from well-defined, approved business context
-- Failed validation prevents wasted effort on premature or poorly defined stories
-
-## Integration Points
-
-- **Input from**: Epic files, previous story status, business stakeholder feedback
-- **Output to**: create_story workflow step (if validation passes)
-- **Dependencies**: Epic documentation standards, story numbering conventions
-- **Escalation**: SM for process issues, architect for technical dependencies

expansion-packs/story-implementation/checklists/story-approval-checklist.md

@@ -1,136 +0,0 @@
-# Story Approval Checklist (Product Owner)
-
-## Purpose
-
-Product Owner validation checklist to approve stories for development. This checklist ensures the story delivers business value, aligns with epic goals, and is ready for the development team.
-
-[[LLM: INITIALIZATION INSTRUCTIONS - STORY APPROVAL VALIDATION
-
-This checklist is for PRODUCT OWNERS to validate stories created by Scrum Master before development begins.
-
-VALIDATION FOCUS:
-1. Business value and alignment
-2. User need satisfaction  
-3. Acceptance criteria accuracy
-4. Scope appropriateness
-5. Development readiness
-
-EXECUTION APPROACH:
-1. Review the story in context of its parent epic
-2. Validate from user/business perspective (not technical)
-3. Focus on "will this deliver the intended value?"
-4. Consider if this is the right story at the right time
-5. Ensure development team has clear success criteria
-
-APPROVAL DECISION:
-- APPROVED: Story ready for development
-- CONDITIONAL: Minor changes needed before approval
-- REJECTED: Significant revision required]]
-
-## Validation Criteria
-
-### 1. BUSINESS VALUE ALIGNMENT
-
-[[LLM: Verify the story actually solves a user problem and contributes to epic goals]]
-
-- [ ] **User Story Clarity**: User story clearly articulates WHO, WHAT, and WHY
-- [ ] **Epic Alignment**: Story directly contributes to epic business objectives  
-- [ ] **Value Proposition**: Clear business or user value from implementing this story
-- [ ] **User Need**: Addresses a real user need (not just technical convenience)
-
-### 2. ACCEPTANCE CRITERIA VALIDATION
-
-[[LLM: ACs must be testable and reflect actual business requirements, not just technical specs]]
-
-- [ ] **Completeness**: ACs cover all essential functionality for the user story
-- [ ] **Business Accuracy**: ACs reflect actual business rules and user expectations
-- [ ] **Testability**: Each AC can be verified through user testing or business validation
-- [ ] **Clarity**: ACs are unambiguous and actionable for development team
-- [ ] **Measurability**: Success criteria are observable and measurable
-
-### 3. SCOPE AND PRIORITY ASSESSMENT
-
-[[LLM: Ensure story is right-sized and appropriately prioritized]]
-
-- [ ] **Scope Appropriateness**: Story scope aligns with project phase and delivery boundaries
-- [ ] **Deliverable Size**: Story can be completed within project's standard delivery timeframe
-- [ ] **Priority Justification**: Story priority aligns with current project objectives and constraints
-- [ ] **Dependency Clarity**: Prerequisites and dependencies are clearly identified
-- [ ] **Risk Assessment**: Business risk of implementing/not implementing is understood
-
-### 4. USER EXPERIENCE CONSIDERATION
-
-[[LLM: From user perspective, does this story make sense and add value?]]
-
-- [ ] **User Journey**: Story fits logically into user workflow and journey
-- [ ] **Usability**: Implementation will result in intuitive user experience
-- [ ] **Edge Cases**: Important user scenarios and edge cases are considered
-- [ ] **Error Handling**: User-facing error scenarios are addressed in ACs
-
-### 5. DEVELOPMENT READINESS
-
-[[LLM: Development team has what they need to succeed]]
-
-- [ ] **Requirements Clarity**: Development team will understand what to build
-- [ ] **Success Definition**: Clear definition of "done" from business perspective  
-- [ ] **Stakeholder Availability**: PO available for clarification during development
-- [ ] **Acceptance Process**: Process for validating completed story is defined
-
-## APPROVAL DECISION
-
-[[LLM: STORY APPROVAL SUMMARY
-
-Based on checklist validation, provide:
-
-1. Approval Decision
-   - APPROVED: Ready for development
-   - CONDITIONAL: Specific changes needed (list them)
-   - REJECTED: Major revision required (explain why)
-
-2. Business Confidence
-   - High: Very confident this delivers intended value
-   - Medium: Some concerns but workable
-   - Low: Significant value or alignment concerns
-
-3. Key Issues (if any)
-   - List specific problems found
-   - Suggest concrete improvements
-   - Identify any business risks
-
-4. Approval Actions
-   - If APPROVED: Update story status to "Approved"
-   - If CONDITIONAL: Document required changes
-   - If REJECTED: Document revision requirements
-
-5. Next Steps
-   - For approved stories: Proceed to development
-   - For conditional: Return to SM with change requests
-   - For rejected: Return to epic planning for revision]]
-
-| Category | Status | Comments |
-|----------|--------|----------|
-| 1. Business Value Alignment | _TBD_ |  |
-| 2. Acceptance Criteria Validation | _TBD_ |  |
-| 3. Scope and Priority Assessment | _TBD_ |  |
-| 4. User Experience Consideration | _TBD_ |  |
-| 5. Development Readiness | _TBD_ |  |
-
-### Final Decision
-
-- [ ] **APPROVED**: Story is ready for development (update status to "Approved")
-- [ ] **CONDITIONAL**: Story needs specific changes before approval (document below)
-- [ ] **REJECTED**: Story requires significant revision (return to epic planning)
-
-### Issues and Required Changes
-
-(Document any specific issues found and changes needed)
-
-### Business Risk Assessment
-
-- **Implementation Risk**: _[High/Medium/Low]_
-- **User Impact**: _[High/Medium/Low]_  
-- **Business Value Confidence**: _[High/Medium/Low]_
-
-### Approval Notes
-
-(Optional: Additional context for development team or future reference)

expansion-packs/story-implementation/manifest.yml

@@ -28,9 +28,7 @@ files:
     - update-epic-progress.md
     - epic-party-mode-retrospective.md
 
-  checklists:
+  checklists: []
-    - story-approval-checklist.md
-    - epic-readiness-checklist.md
 
 # Dependencies on core BMAD components
 dependencies:
@@ -51,6 +49,7 @@ dependencies:
     - architect-checklist.md
     - po-master-checklist.md
     - story-dod-checklist.md
+    - pm-checklist.md
   core_templates:
     - story-tmpl.md
 
@@ -74,7 +73,7 @@ post_install_message: |
   - Epic validation before story creation
   - Project-agnostic code generation and build tool integration
   - Round 1: Comprehensive reviews (Architecture, Business, Process, QA, UX)
-  - Feedback consolidation with REQUIRED-FOR-COMPLETION/QUALITY-STANDARD/IMPROVEMENT classification
+  - Feedback consolidation with REQUIRED-FOR-COMPLETION/QUALITY-STANDARD/IMPROVEMENT/SCOPE-CREEP classification
   - Round 2+: Efficient architect-only validation with browser MCP testing
   - Story status tracking throughout workflow (Draft → Approved → In Progress → Verified → Review → Done → Delivered)
   - Story-based documentation for evidence and tracking

expansion-packs/story-implementation/tasks/approve-story-for-development.md

@@ -16,7 +16,7 @@ Product Owner validation and approval of story for development readiness. Valida
 - Understand the story's role within the epic objectives
 
 ### 2. Execute Story Approval Checklist
-- Use `story-approval-checklist.md` as validation framework
+- Use `pm-checklist.md` as validation framework (sections 4.3, 6.2, 8.2)
 - Systematically evaluate each checklist category:
   - Business Value Alignment
   - Acceptance Criteria Validation  

expansion-packs/story-implementation/tasks/consolidate-review-feedback.md

@@ -1,13 +1,13 @@
 # Consolidate Review Feedback
 
 ## Task Overview
-**Agent:** architect  
+**Agent:** sm  
 **Action Type:** feedback-consolidation  
 **Duration:** 10-15 minutes  
 **LLM-Optimized:** Token-efficient structured consolidation  
 
 ## Purpose
-Consolidate feedback from all Round 1 reviews into prioritized action plan with REQUIRED-FOR-COMPLETION/QUALITY-STANDARD/IMPROVEMENT classification for efficient implementation.
+Consolidate feedback from all Round 1 reviews into prioritized action plan with REQUIRED-FOR-COMPLETION/QUALITY-STANDARD/IMPROVEMENT/SCOPE-CREEP classification for efficient implementation while maintaining story focus.
 
 ## Context
 Central coordination after 5 parallel Round 1 reviews:
@@ -36,6 +36,12 @@ Central coordination after 5 parallel Round 1 reviews:
 
 ### Step 1: Pre-Consolidation Analysis
 
+**Original Story Analysis (CRITICAL FIRST STEP):**
+1. Read original user story and ALL acceptance criteria from story file
+2. Identify explicit requirements vs implicit assumptions
+3. Note any performance, testing, or quality requirements in original AC
+4. Establish baseline: "What was originally agreed as MVP scope?"
+
 **Feedback Source Review:**
 - Architecture: Technical design and implementation issues
 - Business: Requirements and value delivery gaps
@@ -47,6 +53,8 @@ Central coordination after 5 parallel Round 1 reviews:
 ```
 FEEDBACK_ANALYSIS:
 - Total items: [count]
+- Original AC items: [count]
+- Scope expansion items: [count]
 - Overlapping issues: [count]
 - Conflicts identified: [count]
 - Implementation effort: [HIGH/MEDIUM/LOW]
@@ -54,6 +62,16 @@ FEEDBACK_ANALYSIS:
 
 ### Step 2: Priority Classification
 
+**SCOPE-CREEP DETECTION (Scrum Master Responsibility):**
+Before classification, compare ALL feedback against original story acceptance criteria:
+- Read original user story and acceptance criteria from story file
+- Compare each suggestion against original requirements
+- Flag anything NOT explicitly required by acceptance criteria
+- Identify tests/standards beyond project minimums
+- Mark nice-to-have additions that expand scope
+- Apply "strict AC compliance" - if not in original AC = potential scope creep
+- Consult architect for complex technical feasibility questions if needed
+
 **REQUIRED-FOR-COMPLETION** (Blocks story completion):
 - Acceptance criteria gaps
 - Critical functionality breaks
@@ -77,6 +95,15 @@ FEEDBACK_ANALYSIS:
 - Documentation enhancements
 - Process improvements
 
+**SCOPE-CREEP** (Outside original story scope - IGNORE):
+- Features not in original acceptance criteria
+- Tests beyond project minimum standards (unless AC specifies performance requirements)
+- Functionality belonging to future stories
+- Nice-to-have additions not in user story
+- Optimizations not needed for story completion
+- Requirements that expand original scope beyond MVP intent
+- "Should also do X" suggestions where X is not in AC
+
 **Classification Format (Max 50 tokens/item):**
 ```
 [PRIORITY]: [Issue] - [Domain] - [Effort: S/M/L] - [Impact: H/M/L]
@@ -87,14 +114,16 @@ FEEDBACK_ANALYSIS:
 - Technical vs Business conflicts → Acceptance criteria priority
 - Similar issues → Consolidate into single action
 - Priority disputes → Story completion impact assessment
-- Reviewer disagreements → Architecture principles guide
+- Reviewer disagreements → Consult with relevant expert (architect for technical, PO for business)
+- Complex technical conflicts → Escalate to architect consultation
 
 ### Step 4: Implementation Sequencing (3-4 minutes)
 **Sequencing Rules:**
-1. REQUIRED-FOR-COMPLETION (dependency order)
+1. SCOPE-CREEP items → IGNORE (do not implement)
-2. QUALITY-STANDARD (grouped by domain)
+2. REQUIRED-FOR-COMPLETION (dependency order)
-3. Dependencies: Backend → Frontend → Integration
+3. QUALITY-STANDARD (grouped by domain)
-4. Validation checkpoints after major changes
+4. Dependencies: Backend → Frontend → Integration
+5. Validation checkpoints after major changes
 
 **Implementation Groups:**
 ```
@@ -108,7 +137,7 @@ Update story file with:
 
 ```markdown
 ## Review Consolidation Summary
-**Architect:** [Name] | **Date:** [YYYY-MM-DD] | **Duration:** [X minutes]
+**Scrum Master:** [Name] | **Date:** [YYYY-MM-DD] | **Duration:** [X minutes]
 
 ### Round 1 Review Results
 - Architecture: [PASS/ISSUES] ([X] items)
@@ -127,6 +156,9 @@ Update story file with:
 #### IMPROVEMENT ([X] items)
 - [Issue] - [Domain] - [Effort] - [Value] | Max 50 tokens
 
+#### SCOPE-CREEP ([X] items - IGNORED)
+- [Issue] - [Domain] - [Reason: Outside AC/Future Story/Nice-to-have] | Max 50 tokens
+
 ### Implementation Sequence
 **Phase 1:** [Critical fixes] - Est: [time] - Items: [count]
 **Phase 2:** [Quality fixes] - Est: [time] - Items: [count]
@@ -143,8 +175,10 @@ Update story file with:
 
 ## Success Criteria
 - [ ] All 5 review streams analyzed and categorized
-- [ ] Conflicts resolved with clear rationale
+- [ ] Original acceptance criteria reviewed and compared against all feedback
-- [ ] Priority classification complete (3 categories)
+- [ ] Scope creep identified by Scrum Master and marked as IGNORE
+- [ ] Conflicts resolved with clear rationale (architect consulted for technical disputes)
+- [ ] Priority classification complete (4 categories)
 - [ ] Implementation sequence with time estimates
 - [ ] Story file updated with structured summary
 - [ ] Action items under 50 tokens each
@@ -186,4 +220,5 @@ If conflicts cannot be resolved:
 - **Input from:** Round 1 reviews (architect, po, sm, qa, ux-expert)
 - **Output to:** implement-consolidated-fixes task (dev agent)
 - **Dependencies:** All Round 1 review checklists must be complete
+- **Consultation:** Architect available for complex technical dispute resolution
 - **Validation:** Next phase will validate using story docs + Playwright MCP

expansion-packs/story-implementation/workflows/story-implementation.yml

@@ -119,7 +119,7 @@ workflow:
       action: execute-checklist
       inputs:
         - epic_number
-      checklist: epic-readiness-checklist.md
+      checklist: po-master-checklist.md
       notes: "REQUIRED: Use Task tool for execution - Validate epic business readiness and dependencies before story creation"
       story_status_update: "N/A - No story exists yet"
       
@@ -234,7 +234,7 @@ workflow:
       checklist_completion_tracking: true
       
     - step: consolidate_feedback
-      agent: architect
+      agent: sm
       action: consolidate-review-feedback
       requires: [round1_architecture_review, round1_business_review, round1_process_review, round1_qa_review, round1_ux_review]
       inputs:
@@ -244,7 +244,7 @@ workflow:
         - process_feedback
         - qa_feedback
         - ux_feedback
-      notes: "REQUIRED: Use Task tool for execution - Architect consolidates all review feedback with REQUIRED-FOR-COMPLETION/QUALITY-STANDARD/IMPROVEMENT classification"
+      notes: "REQUIRED: Use Task tool for execution - Scrum Master consolidates all review feedback with REQUIRED-FOR-COMPLETION/QUALITY-STANDARD/IMPROVEMENT/SCOPE-CREEP classification. Compare ALL feedback against original acceptance criteria to identify scope creep."
       
     - step: implement_fixes
       agent: dev
@@ -491,9 +491,7 @@ workflow:
       - create-comprehensive-pr
       - update-epic-progress
       - epic-party-mode-retrospective
-    expansion_checklists:
+    expansion_checklists: []
-      - story-approval-checklist.md
-      - epic-readiness-checklist.md
 
   handoff_prompts:
     po_validate_epic: "Validate epic {epic_number} readiness for story creation - check approval status, dependencies, and business context"