feat: implement centralized shard configuration and optimize workflow structure
- Add shard_configuration to workflow with centralized naming patterns - Update SM responsibilities for validation and learning facilitation - Optimize task inputs/outputs for parallel processing with dedicated shards - Improve workflow clarity with explicit shard mappings - Format all story-implementation files for consistency 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
2-gabadi
parent
f034282b6d
commit
bf499b1cae
|
|
@ -0,0 +1,10 @@
|
|||
# Default ignored files
|
||||
/shelf/
|
||||
/workspace.xml
|
||||
# Editor-based HTTP Client requests
|
||||
/httpRequests/
|
||||
# Environment-dependent path to Maven home directory
|
||||
/mavenHomeManager.xml
|
||||
# Datasource local storage ignored files
|
||||
/dataSources/
|
||||
/dataSources.local.xml
|
||||
|
|
@ -1,10 +1,13 @@
|
|||
# Story Implementation Expansion Pack
|
||||
|
||||
## Overview
|
||||
|
||||
Comprehensive end-to-end story implementation workflows with dual-variant approach, extensive validation systems, and intelligent learning extraction. Transforms epic context into production-ready deliverables with built-in quality gates and continuous improvement mechanisms.
|
||||
|
||||
## Purpose
|
||||
|
||||
Addresses the complexity gap in agile story implementation by providing:
|
||||
|
||||
- **Progressive validation**: Epic readiness → Story approval → Implementation → Quality review
|
||||
- **Dual workflow variants**: Simple (9 steps, 2-3 days) vs Standard (15 steps, 4-5 days)
|
||||
- **Comprehensive review system**: Round 1 multi-agent reviews + Round 2+ efficient validation
|
||||
|
|
@ -14,24 +17,28 @@ Addresses the complexity gap in agile story implementation by providing:
|
|||
## When to Use This Pack
|
||||
|
||||
### Use story-simple workflow for:
|
||||
|
||||
- UI/UX improvements and content updates
|
||||
- Simple bug fixes and configuration changes
|
||||
- Minor backend adjustments
|
||||
- Straightforward feature toggles
|
||||
|
||||
### Use story-implementation workflow for:
|
||||
|
||||
- New feature development with business logic
|
||||
- Database schema changes and migrations
|
||||
- Database schema changes and migrations
|
||||
- Cross-system integrations
|
||||
- Complex user workflows and state management
|
||||
|
||||
## What's Included
|
||||
|
||||
### Workflows
|
||||
|
||||
- **story-simple.yml**: Streamlined 9-step workflow for simple changes
|
||||
- **story-implementation.yml**: Comprehensive 15-step workflow for complex features
|
||||
|
||||
### Tasks
|
||||
|
||||
- **approve-story-for-development.md**: Product Owner validation and approval
|
||||
- **setup-development-environment.md**: Environment preparation and validation
|
||||
- **implement-story-development.md**: Project-agnostic implementation with build integration
|
||||
|
|
@ -46,6 +53,7 @@ Addresses the complexity gap in agile story implementation by providing:
|
|||
- **epic-party-mode-retrospective.md**: Automatic epic retrospective with multi-agent analysis
|
||||
|
||||
### Checklists
|
||||
|
||||
- Uses bmad-core checklists via execute-checklist task:
|
||||
- **po-master-checklist.md**: Epic readiness and business validation
|
||||
- **pm-checklist.md**: Story approval and acceptance criteria validation
|
||||
|
|
@ -54,6 +62,7 @@ Addresses the complexity gap in agile story implementation by providing:
|
|||
## Integration with Core BMAD
|
||||
|
||||
### Required Core Agents
|
||||
|
||||
- **sm** (Scrum Master): Workflow orchestration and process management
|
||||
- **po** (Product Owner): Business validation and story approval
|
||||
- **dev** (Developer): Implementation execution and code quality
|
||||
|
|
@ -63,6 +72,7 @@ Addresses the complexity gap in agile story implementation by providing:
|
|||
- **infra-devops-platform** (DevOps): Environment and infrastructure management
|
||||
|
||||
### Core Components Integration
|
||||
|
||||
- Leverages existing **story-tmpl.md** for consistent story structure
|
||||
- Uses **story-draft-checklist.md** for initial story validation
|
||||
- Integrates with **create-next-story** task for epic progression
|
||||
|
|
@ -81,6 +91,7 @@ bmad list expansion-packs
|
|||
## Usage Examples
|
||||
|
||||
### Simple Story Implementation
|
||||
|
||||
```bash
|
||||
# For UI changes, content updates, simple fixes
|
||||
*workflow story-simple epic_number=5 story_number=3
|
||||
|
|
@ -88,7 +99,8 @@ bmad list expansion-packs
|
|||
# Example output: Epic 5, Story 3 implemented with 9 validation steps
|
||||
```
|
||||
|
||||
### Full Feature Implementation
|
||||
### Full Feature Implementation
|
||||
|
||||
```bash
|
||||
# For complex features, business logic, integrations
|
||||
*workflow story-implementation epic_number=12 story_number=7
|
||||
|
|
@ -97,28 +109,32 @@ bmad list expansion-packs
|
|||
```
|
||||
|
||||
### Workflow Selection Validation
|
||||
|
||||
Both workflows include complexity validation warnings to ensure appropriate selection based on:
|
||||
|
||||
- Implementation scope and complexity
|
||||
- Business logic requirements
|
||||
- Business logic requirements
|
||||
- Integration touchpoints
|
||||
- Quality validation needs
|
||||
|
||||
## Workflow Selection Guide
|
||||
|
||||
| Criteria | story-simple | story-implementation |
|
||||
|----------|--------------|---------------------|
|
||||
| **Duration** | 2-3 days | 4-5 days |
|
||||
| **Steps** | 9 optimized steps | 15 comprehensive steps |
|
||||
| **Code Changes** | Single component focus | Multi-component integration |
|
||||
| **Business Logic** | Minimal/none | Significant business rules |
|
||||
| **Database Changes** | Read-only or minor | Schema changes, migrations |
|
||||
| **Testing Scope** | Component-level | Integration and system-level |
|
||||
| **Review Rounds** | Single efficient round | Multi-round comprehensive |
|
||||
| Criteria | story-simple | story-implementation |
|
||||
| -------------------- | ---------------------- | ---------------------------- |
|
||||
| **Duration** | 2-3 days | 4-5 days |
|
||||
| **Steps** | 9 optimized steps | 15 comprehensive steps |
|
||||
| **Code Changes** | Single component focus | Multi-component integration |
|
||||
| **Business Logic** | Minimal/none | Significant business rules |
|
||||
| **Database Changes** | Read-only or minor | Schema changes, migrations |
|
||||
| **Testing Scope** | Component-level | Integration and system-level |
|
||||
| **Review Rounds** | Single efficient round | Multi-round comprehensive |
|
||||
|
||||
## Team Integration
|
||||
|
||||
### Agent Team Configuration
|
||||
|
||||
Add to your team configuration files:
|
||||
|
||||
```yaml
|
||||
expansion_packs:
|
||||
- story-implementation
|
||||
|
|
@ -127,13 +143,14 @@ workflows:
|
|||
story_simple:
|
||||
trigger: "story-simple"
|
||||
agents: [sm, po, dev, architect]
|
||||
|
||||
|
||||
story_implementation:
|
||||
trigger: "story-implementation"
|
||||
trigger: "story-implementation"
|
||||
agents: [sm, po, dev, architect, qa, ux-expert, infra-devops-platform]
|
||||
```
|
||||
|
||||
### Role Assignments
|
||||
|
||||
- **SM**: Workflow orchestration, process compliance, team coordination
|
||||
- **PO**: Business validation, story approval, value assessment
|
||||
- **Dev**: Implementation execution, code quality, technical fixes
|
||||
|
|
@ -145,19 +162,22 @@ workflows:
|
|||
## Learning System
|
||||
|
||||
### Six Learning Categories
|
||||
|
||||
1. **ARCH_CHANGE**: Architecture improvements and technical debt
|
||||
2. **FUTURE_EPIC**: Epic candidates and feature opportunities
|
||||
2. **FUTURE_EPIC**: Epic candidates and feature opportunities
|
||||
3. **URGENT_FIX**: Critical issues requiring immediate attention
|
||||
4. **PROCESS_IMPROVEMENT**: Development workflow enhancements
|
||||
5. **TOOLING**: Infrastructure and automation improvements
|
||||
6. **KNOWLEDGE_GAP**: Team training and skill development needs
|
||||
|
||||
### Learning Flow
|
||||
|
||||
```
|
||||
Implementation → Learning Triage → Collaborative Review → Epic Integration → Retrospective
|
||||
```
|
||||
|
||||
### Learning Integration
|
||||
|
||||
- **Story Level**: Individual story learning capture and triage
|
||||
- **Epic Level**: Aggregated learning analysis and pattern identification
|
||||
- **Team Level**: Collaborative review sessions with consensus building
|
||||
|
|
@ -166,12 +186,14 @@ Implementation → Learning Triage → Collaborative Review → Epic Integration
|
|||
## Epic Management
|
||||
|
||||
### Epic Progress Tracking
|
||||
|
||||
- Automatic story completion percentage calculation
|
||||
- Learning integration across all epic stories
|
||||
- Epic health monitoring and risk assessment
|
||||
- Completion milestone triggers
|
||||
|
||||
### Epic Retrospective System
|
||||
|
||||
- **Trigger**: Automatic when epic reaches 100% completion
|
||||
- **Participants**: Multi-agent collaborative analysis (SM, Architect, PO, Dev, UX-Expert)
|
||||
- **Output**: Strategic insights, action items, knowledge base creation
|
||||
|
|
@ -180,12 +202,14 @@ Implementation → Learning Triage → Collaborative Review → Epic Integration
|
|||
## Dependencies
|
||||
|
||||
### Core BMAD Components Required
|
||||
|
||||
- bmad-core v4.0+ (agent framework and core tasks)
|
||||
- Core agent definitions (sm, po, dev, architect, qa, ux-expert, infra-devops-platform)
|
||||
- Core templates (story-tmpl.md, story-draft-checklist.md)
|
||||
- Core workflow engine and Task tool execution capabilities
|
||||
|
||||
### External Dependencies
|
||||
|
||||
- Git repository with proper branch management
|
||||
- Build system integration (detected automatically)
|
||||
- Project-specific testing tools (as defined in project documentation)
|
||||
|
|
@ -194,21 +218,27 @@ Implementation → Learning Triage → Collaborative Review → Epic Integration
|
|||
## Customization
|
||||
|
||||
### Workflow Customization
|
||||
|
||||
Modify workflow files to adjust:
|
||||
|
||||
- Task sequence and dependencies
|
||||
- Agent assignments and responsibilities
|
||||
- Quality gate criteria and thresholds
|
||||
- Learning extraction categories and priorities
|
||||
|
||||
### Task Customization
|
||||
|
||||
Individual tasks can be customized for:
|
||||
|
||||
- Organization-specific validation criteria
|
||||
- Custom build and test integration
|
||||
- Extended learning categories
|
||||
- Modified review and approval processes
|
||||
|
||||
### Template Integration
|
||||
|
||||
Customize story and epic templates to match:
|
||||
|
||||
- Organization documentation standards
|
||||
- Business context requirements
|
||||
- Technical architecture patterns
|
||||
|
|
@ -217,6 +247,7 @@ Customize story and epic templates to match:
|
|||
## Notes
|
||||
|
||||
⚠️ **Important Considerations:**
|
||||
|
||||
- Both workflows require Task tool execution for proper expansion pack compliance
|
||||
- Epic files must exist and be properly formatted before story creation
|
||||
- Learning system requires structured documentation for maximum effectiveness
|
||||
|
|
@ -224,18 +255,21 @@ Customize story and epic templates to match:
|
|||
- Epic retrospective triggers automatically - ensure team availability for collaborative sessions
|
||||
|
||||
🔧 **Performance Optimization:**
|
||||
|
||||
- Simple workflow optimized for rapid iteration on straightforward changes
|
||||
- Implementation workflow designed for comprehensive validation of complex features
|
||||
- Learning system token-optimized for efficient LLM processing
|
||||
- Review consolidation reduces validation overhead in subsequent rounds
|
||||
|
||||
📊 **Quality Metrics:**
|
||||
|
||||
- Built-in complexity validation prevents workflow misselection
|
||||
- Multi-round review system ensures comprehensive quality validation
|
||||
- Learning extraction drives continuous process improvement
|
||||
- Epic progress tracking provides visibility into delivery health
|
||||
|
||||
---
|
||||
|
||||
_Version: 1.0.0_
|
||||
_Compatible with: BMAD Method v4.0+_
|
||||
_Build on: Core bmad-method components for maximum reliability_
|
||||
_Build on: Core bmad-method components for maximum reliability_
|
||||
|
|
|
|||
|
|
@ -1,81 +1,95 @@
|
|||
# Approve Story for Development
|
||||
|
||||
## Purpose
|
||||
|
||||
Product Owner validation and approval of story for development readiness. Validates business value, epic alignment, and acceptance criteria accuracy before development begins.
|
||||
|
||||
## Inputs
|
||||
|
||||
- `story_file`: Path to the story file requiring approval (e.g., "docs/stories/epic1.story2.story.md")
|
||||
- `epic_number`: Epic number for alignment validation
|
||||
|
||||
## Task Execution
|
||||
|
||||
### 1. Load Story and Epic Context
|
||||
|
||||
- Read the complete story file
|
||||
- Read the parent epic file (located via `docs/prd/epic-{epic_number}-*.md` or `docs/epics/epic-{epic_number}-*.md`) for context
|
||||
- Extract story status, user story, acceptance criteria, and business context
|
||||
- Understand the story's role within the epic objectives
|
||||
|
||||
### 2. Execute Story Approval Checklist
|
||||
|
||||
- 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
|
||||
- Acceptance Criteria Validation
|
||||
- Scope and Priority Assessment
|
||||
- User Experience Consideration
|
||||
- Development Readiness
|
||||
|
||||
### 3. Business Value Assessment
|
||||
|
||||
- Validate user story articulates clear WHO, WHAT, WHY
|
||||
- Confirm story contributes meaningfully to epic business objectives
|
||||
- Assess if story addresses real user need vs technical convenience
|
||||
- Evaluate business risk of implementing vs not implementing
|
||||
|
||||
### 4. Acceptance Criteria Validation
|
||||
|
||||
- Review each AC for business accuracy and completeness
|
||||
- Ensure ACs reflect actual business rules and user expectations
|
||||
- Verify ACs are testable from user/business perspective
|
||||
- Check for clarity and measurability of success criteria
|
||||
|
||||
### 5. Scope and Priority Review
|
||||
|
||||
- Validate story scope aligns with MVP boundaries
|
||||
- Confirm story can be completed in single iteration
|
||||
- Assess priority appropriateness for current epic phase
|
||||
- Review dependencies and prerequisites
|
||||
|
||||
### 6. User Experience Evaluation
|
||||
|
||||
- Consider story impact on overall user journey
|
||||
- Evaluate usability implications of proposed functionality
|
||||
- Review edge cases and error scenarios from user perspective
|
||||
- Assess integration with existing user workflows
|
||||
|
||||
### 7. Development Readiness Check
|
||||
|
||||
- Confirm development team will have clear requirements
|
||||
- Validate success criteria are well-defined
|
||||
- Ensure PO availability for clarification during development
|
||||
- Review acceptance process for completed story
|
||||
|
||||
### 8. Make Approval Decision
|
||||
|
||||
Based on checklist validation, determine:
|
||||
|
||||
**APPROVED**:
|
||||
**APPROVED**:
|
||||
|
||||
- All critical criteria met
|
||||
- Story ready for development
|
||||
- Update story status to "Approved"
|
||||
- Log approval decision and timestamp
|
||||
|
||||
**CONDITIONAL**:
|
||||
|
||||
- Minor issues requiring specific changes
|
||||
- Document required changes clearly
|
||||
- Keep story status as "Draft"
|
||||
- Provide actionable feedback for revision
|
||||
|
||||
**REJECTED**:
|
||||
|
||||
- Significant issues requiring major revision
|
||||
- Keep story status as "Draft"
|
||||
- Keep story status as "Draft"
|
||||
- Document revision requirements
|
||||
- Return to epic planning if needed
|
||||
|
||||
### 9. Document Decision and Next Steps
|
||||
|
||||
- Record approval decision in story file
|
||||
- Add PO approval section with:
|
||||
- Decision (APPROVED/CONDITIONAL/REJECTED)
|
||||
|
|
@ -86,6 +100,7 @@ Based on checklist validation, determine:
|
|||
- Update story status appropriately
|
||||
|
||||
## Success Criteria
|
||||
|
||||
- Story has been thoroughly evaluated from business perspective
|
||||
- Clear approval decision made with supporting rationale
|
||||
- Story status updated according to decision
|
||||
|
|
@ -93,20 +108,23 @@ Based on checklist validation, determine:
|
|||
- Development team has clear guidance for proceeding
|
||||
|
||||
## Outputs
|
||||
|
||||
- `approval_decision`: "APPROVED", "CONDITIONAL", or "REJECTED"
|
||||
- `story_status`: Updated story status ("Approved" or remains "Draft")
|
||||
- `business_confidence`: Risk assessment of story value delivery
|
||||
- `required_changes`: List of changes needed (if conditional/rejected)
|
||||
|
||||
## Failure Actions
|
||||
|
||||
- If story has critical business value issues: REJECTED with specific feedback
|
||||
- If epic alignment is unclear: Request epic clarification before proceeding
|
||||
- If ACs don't reflect business needs: CONDITIONAL with AC revision requirements
|
||||
- If scope too large: CONDITIONAL with scope reduction guidance
|
||||
|
||||
## Quality Gates
|
||||
|
||||
- All checklist categories evaluated with evidence
|
||||
- Business value clearly articulated and validated
|
||||
- Epic alignment confirmed with specific examples
|
||||
- ACs tested against real user scenarios mentally
|
||||
- Development readiness confirmed from PO perspective
|
||||
- Development readiness confirmed from PO perspective
|
||||
|
|
|
|||
|
|
@ -1,21 +1,25 @@
|
|||
# Capture Learning Triage
|
||||
|
||||
## Task Overview
|
||||
|
||||
**Agent:** architect
|
||||
**Action Type:** learning-triage
|
||||
**Duration:** 10-15 minutes
|
||||
**LLM-Optimized:** Token-efficient structured capture
|
||||
**LLM-Optimized:** Token-efficient structured capture
|
||||
|
||||
## Purpose
|
||||
|
||||
Systematically capture and triage learnings from story implementation to drive continuous improvement and feed future epics.
|
||||
|
||||
## Inputs
|
||||
|
||||
- Story implementation file (docs/stories/epic{epic_number}.story{story_number}.story.md)
|
||||
- All review feedback from Round 1 reviews
|
||||
- Implementation fixes and changes
|
||||
- Quality gate results and metrics
|
||||
|
||||
## Outputs
|
||||
|
||||
- Learning items captured in story file under ## Learning Triage section
|
||||
- Categorized learning items with priorities and owners
|
||||
- Action items for immediate and future implementation
|
||||
|
|
@ -23,6 +27,7 @@ Systematically capture and triage learnings from story implementation to drive c
|
|||
## Learning Categories
|
||||
|
||||
### ARCH_CHANGE (Architecture Changes Required)
|
||||
|
||||
- **Purpose:** Technical debt or architecture improvements identified
|
||||
- **Token Limit:** 50 tokens per item
|
||||
- **Format:** `ARCH: [Component] - [Issue] - [Impact] - [Owner: architect]`
|
||||
|
|
@ -30,20 +35,23 @@ Systematically capture and triage learnings from story implementation to drive c
|
|||
- **Timeline:** Current epic / Next epic / Technical debt backlog
|
||||
|
||||
### FUTURE_EPIC (Epic Candidate Features)
|
||||
- **Purpose:** Features or capabilities that emerged during implementation
|
||||
|
||||
- **Purpose:** Features or capabilities that emerged during implementation
|
||||
- **Token Limit:** 50 tokens per item
|
||||
- **Format:** `EPIC: [Feature] - [Business Value] - [Complexity] - [Owner: po]`
|
||||
- **Priority:** HIGH/MEDIUM/LOW
|
||||
- **Timeline:** Next sprint / Next quarter / Future roadmap
|
||||
|
||||
### URGENT_FIX (Critical Issues Requiring Immediate Attention)
|
||||
|
||||
- **Purpose:** Blockers or critical issues that need immediate resolution
|
||||
- **Token Limit:** 50 tokens per item
|
||||
- **Token Limit:** 50 tokens per item
|
||||
- **Format:** `URGENT: [Issue] - [Impact] - [Fix Required] - [Owner: dev/architect]`
|
||||
- **Priority:** CRITICAL (resolve within current sprint)
|
||||
- **Timeline:** Immediate (within 1-2 days)
|
||||
|
||||
### PROCESS_IMPROVEMENT (Development Process Enhancements)
|
||||
|
||||
- **Purpose:** Workflow, tooling, or process improvements identified
|
||||
- **Token Limit:** 50 tokens per item
|
||||
- **Format:** `PROCESS: [Area] - [Current State] - [Improvement] - [Owner: sm]`
|
||||
|
|
@ -51,6 +59,7 @@ Systematically capture and triage learnings from story implementation to drive c
|
|||
- **Timeline:** Current sprint / Next sprint / Continuous improvement
|
||||
|
||||
### TOOLING (Development Tooling and Infrastructure)
|
||||
|
||||
- **Purpose:** Tools, automation, or infrastructure improvements needed
|
||||
- **Token Limit:** 50 tokens per item
|
||||
- **Format:** `TOOLING: [Tool/System] - [Gap] - [Solution] - [Owner: infra-devops-platform]`
|
||||
|
|
@ -58,6 +67,7 @@ Systematically capture and triage learnings from story implementation to drive c
|
|||
- **Timeline:** Current sprint / Next sprint / Infrastructure roadmap
|
||||
|
||||
### KNOWLEDGE_GAP (Team Knowledge and Training Needs)
|
||||
|
||||
- **Purpose:** Skills, knowledge, or training gaps identified during implementation
|
||||
- **Token Limit:** 50 tokens per item
|
||||
- **Format:** `KNOWLEDGE: [Area] - [Gap] - [Training Need] - [Owner: sm/po]`
|
||||
|
|
@ -67,6 +77,7 @@ Systematically capture and triage learnings from story implementation to drive c
|
|||
## Execution Steps
|
||||
|
||||
### Step 1: Review Implementation Context
|
||||
|
||||
```
|
||||
CONTEXT_REVIEW:
|
||||
- Story complexity: [SIMPLE/MODERATE/COMPLEX]
|
||||
|
|
@ -77,14 +88,17 @@ CONTEXT_REVIEW:
|
|||
```
|
||||
|
||||
### Step 2: Extract Learning Items
|
||||
|
||||
For each category, scan implementation evidence:
|
||||
|
||||
- Review feedback patterns
|
||||
- Implementation fix patterns
|
||||
- Implementation fix patterns
|
||||
- Quality gate failure patterns
|
||||
- Time/effort variance patterns
|
||||
- Technical decision points
|
||||
|
||||
### Step 3: Triage and Prioritize
|
||||
|
||||
```
|
||||
TRIAGE_MATRIX:
|
||||
High Priority: Blocks current/next sprint, affects team velocity
|
||||
|
|
@ -93,16 +107,18 @@ Low Priority: Nice-to-have improvements, long-term optimization
|
|||
```
|
||||
|
||||
### Step 4: Assign Owners and Timelines
|
||||
|
||||
```
|
||||
OWNERSHIP_ASSIGNMENT:
|
||||
- architect: Architecture, technical debt, system design
|
||||
- po: Business features, epic candidates, requirements
|
||||
- dev: Implementation issues, code quality, technical fixes
|
||||
- sm: Process improvements, team coordination, knowledge gaps
|
||||
- sm: Process improvements, team coordination, knowledge gaps
|
||||
- infra-devops-platform: Tooling, infrastructure, automation
|
||||
```
|
||||
|
||||
## Success Criteria
|
||||
|
||||
- [ ] All learning categories reviewed and populated
|
||||
- [ ] Each item under 50 tokens with clear action owner
|
||||
- [ ] Priority and timeline assigned to each item
|
||||
|
|
@ -111,40 +127,51 @@ OWNERSHIP_ASSIGNMENT:
|
|||
- [ ] Learning items added to story file under ## Learning Triage
|
||||
|
||||
## Evidence Documentation
|
||||
|
||||
Update story file with:
|
||||
|
||||
```markdown
|
||||
## Learning Triage
|
||||
|
||||
**Architect:** [Name] | **Date:** [YYYY-MM-DD] | **Duration:** [X minutes]
|
||||
|
||||
### ARCH_CHANGE
|
||||
|
||||
- ARCH: [Component] - [Issue] - [Impact] - [Owner: architect] | Priority: [HIGH/MEDIUM/LOW] | Timeline: [Current/Next/Backlog]
|
||||
|
||||
### FUTURE_EPIC
|
||||
### FUTURE_EPIC
|
||||
|
||||
- EPIC: [Feature] - [Business Value] - [Complexity] - [Owner: po] | Priority: [HIGH/MEDIUM/LOW] | Timeline: [Next/Quarter/Future]
|
||||
|
||||
### URGENT_FIX
|
||||
|
||||
- URGENT: [Issue] - [Impact] - [Fix Required] - [Owner: dev/architect] | Priority: CRITICAL | Timeline: Immediate
|
||||
|
||||
### PROCESS_IMPROVEMENT
|
||||
|
||||
- PROCESS: [Area] - [Current State] - [Improvement] - [Owner: sm] | Priority: [HIGH/MEDIUM/LOW] | Timeline: [Current/Next/Continuous]
|
||||
|
||||
### TOOLING
|
||||
|
||||
- TOOLING: [Tool/System] - [Gap] - [Solution] - [Owner: infra-devops-platform] | Priority: [HIGH/MEDIUM/LOW] | Timeline: [Current/Next/Infrastructure]
|
||||
|
||||
### KNOWLEDGE_GAP
|
||||
|
||||
- KNOWLEDGE: [Area] - [Gap] - [Training Need] - [Owner: sm/po] | Priority: [HIGH/MEDIUM/LOW] | Timeline: [Current/Next/Long-term]
|
||||
|
||||
**Summary:** [X items captured] | [X urgent] | [X epic candidates] | [X process improvements]
|
||||
```
|
||||
|
||||
## Integration Points
|
||||
|
||||
- **Input from:** validate_fixes (final architect review)
|
||||
- **Output to:** party-mode-learning-review (collaborative review)
|
||||
- **Handoff:** "Learning triage complete. Ready for collaborative review session."
|
||||
|
||||
## LLM Optimization Notes
|
||||
|
||||
- Token limits enforce brevity and focus
|
||||
- Structured format enables rapid scanning
|
||||
- Evidence-based categorization reduces subjective interpretation
|
||||
- Clear ownership prevents action item limbo
|
||||
- Timeline specificity enables proper backlog management
|
||||
- Timeline specificity enables proper backlog management
|
||||
|
|
|
|||
|
|
@ -1,21 +1,25 @@
|
|||
# Commit and Prepare PR
|
||||
|
||||
## Task Overview
|
||||
|
||||
**Agent:** dev
|
||||
**Action Type:** git-commit-and-pr-preparation
|
||||
**Duration:** 5-10 minutes
|
||||
**LLM-Optimized:** Structured commit and context generation
|
||||
**LLM-Optimized:** Structured commit and context generation
|
||||
|
||||
## Purpose
|
||||
|
||||
Commit all story implementation changes with comprehensive context and prepare detailed PR context for comprehensive review and delivery.
|
||||
|
||||
## Inputs
|
||||
|
||||
- Story implementation file with complete learning review results
|
||||
- All implementation code changes
|
||||
- Test results and quality gate confirmations
|
||||
- Review feedback and learning items
|
||||
|
||||
## Outputs
|
||||
|
||||
- Git commit with story implementation changes
|
||||
- Comprehensive PR context prepared
|
||||
- Story file updated with commit information
|
||||
|
|
@ -24,16 +28,18 @@ Commit all story implementation changes with comprehensive context and prepare d
|
|||
## Execution Steps
|
||||
|
||||
### Step 1: Pre-Commit Validation (2 minutes)
|
||||
|
||||
```
|
||||
PRE_COMMIT_CHECKLIST:
|
||||
- [ ] All quality gates passing
|
||||
- [ ] Story file updated with learning review results
|
||||
- [ ] Story file updated with learning review results
|
||||
- [ ] Implementation code complete and tested
|
||||
- [ ] No uncommitted changes remaining
|
||||
- [ ] Branch synchronized with latest main/develop
|
||||
```
|
||||
|
||||
### Step 2: Generate Commit Message (2 minutes)
|
||||
|
||||
```
|
||||
COMMIT_MESSAGE_FORMAT:
|
||||
[Epic-Story] Brief implementation summary
|
||||
|
|
@ -43,7 +49,7 @@ Type: [feature/enhancement/fix/refactor]
|
|||
|
||||
Implementation Summary:
|
||||
- [Key change 1 - max 50 tokens]
|
||||
- [Key change 2 - max 50 tokens]
|
||||
- [Key change 2 - max 50 tokens]
|
||||
- [Key change 3 - max 50 tokens]
|
||||
|
||||
Quality Gates: [PASS/FAIL counts]
|
||||
|
|
@ -58,6 +64,7 @@ Co-Authored-By: Claude <noreply@anthropic.com>
|
|||
```
|
||||
|
||||
### Step 3: Commit Implementation (1 minute)
|
||||
|
||||
```bash
|
||||
# Add all story-related changes
|
||||
git add .
|
||||
|
|
@ -89,12 +96,14 @@ EOF
|
|||
```
|
||||
|
||||
### Step 4: Prepare PR Context (3-5 minutes)
|
||||
|
||||
Generate comprehensive PR context document:
|
||||
|
||||
```markdown
|
||||
# PR Context: Epic {epic_number}.{story_number}
|
||||
|
||||
## Business Summary
|
||||
|
||||
**Epic:** {epic_title}
|
||||
**Epic Progress:** {epic_completion_percentage}% complete ({completed_stories}/{total_stories} stories)
|
||||
**Story:** {story_title}
|
||||
|
|
@ -104,53 +113,67 @@ Generate comprehensive PR context document:
|
|||
**Epic Retrospective:** {MANDATORY_AUTO_TRIGGERED/PENDING/NOT_REQUIRED}
|
||||
|
||||
### Epic Completion Status
|
||||
|
||||
**If Epic Complete (100%):**
|
||||
|
||||
- 🎉 **EPIC COMPLETION ACHIEVED!** Epic {epic_number} is now 100% complete
|
||||
- 📊 **Epic Retrospective:** MANDATORY and automatically triggered
|
||||
- 🎆 **Epic Celebration:** Multi-agent retrospective scheduled for strategic insights
|
||||
- 🎣 **Next Epic Preparation:** Action items will be generated during retrospective
|
||||
|
||||
**If Epic In Progress (<100%):**
|
||||
|
||||
- 🚧 **Epic Progress:** {epic_completion_percentage}% complete, {remaining_stories} stories remaining
|
||||
- 📅 **Next Story:** Story {next_story_number} ready for development
|
||||
- 🔄 **Epic Timeline:** On track for completion by {projected_completion_date}
|
||||
|
||||
### Business Value
|
||||
|
||||
- {business_impact_1}
|
||||
- {business_impact_2}
|
||||
- {business_impact_3}
|
||||
|
||||
## Technical Changes
|
||||
|
||||
### Implementation Summary
|
||||
|
||||
- {technical_change_1} | Impact: {HIGH/MEDIUM/LOW}
|
||||
- {technical_change_2} | Impact: {HIGH/MEDIUM/LOW}
|
||||
- {technical_change_3} | Impact: {HIGH/MEDIUM/LOW}
|
||||
|
||||
### Quality Metrics
|
||||
|
||||
- **Tests:** {test_count} added, {existing_test_count} updated
|
||||
- **Code Coverage:** {coverage_percentage}%
|
||||
- **Quality Gates:** {pass_count} PASS, {fail_count} FAIL
|
||||
- **Review Rounds:** {review_rounds}
|
||||
|
||||
### Architecture Impact
|
||||
|
||||
- {architecture_impact_1}
|
||||
- {architecture_impact_2}
|
||||
|
||||
## Learning Extraction
|
||||
|
||||
### Immediate Actions (Current Sprint)
|
||||
|
||||
- {immediate_action_1} - {owner} - Due: {date}
|
||||
- {immediate_action_2} - {owner} - Due: {date}
|
||||
|
||||
### Next Sprint Integration
|
||||
|
||||
- {next_sprint_action_1} - {owner}
|
||||
- {next_sprint_action_2} - {owner}
|
||||
|
||||
### Future Epic Candidates
|
||||
|
||||
- {epic_candidate_1} - Priority: {HIGH/MEDIUM/LOW}
|
||||
- {epic_candidate_2} - Priority: {HIGH/MEDIUM/LOW}
|
||||
|
||||
### Epic Retrospective Context (if Epic Complete)
|
||||
|
||||
**Epic Retrospective Data Prepared:**
|
||||
|
||||
- All {total_stories} story files consolidated
|
||||
- {total_learning_items} learning items across epic
|
||||
- Epic metrics: {avg_quality_score}/10 quality, {epic_duration} days duration
|
||||
|
|
@ -160,23 +183,28 @@ Generate comprehensive PR context document:
|
|||
**Epic Retrospective Status:** {MANDATORY_TRIGGERED/NOT_APPLICABLE}
|
||||
|
||||
## Validation Evidence
|
||||
|
||||
### Pre-Review Validation
|
||||
|
||||
- {validation_item_1}: PASS
|
||||
- {validation_item_2}: PASS
|
||||
- {validation_item_3}: PASS
|
||||
|
||||
### Review Results
|
||||
|
||||
- **Architecture Review:** {PASS/ADDRESSED}
|
||||
- **Business Review:** {PASS/ADDRESSED}
|
||||
- **QA Review:** {PASS/ADDRESSED}
|
||||
- **UX Review:** {PASS/ADDRESSED}
|
||||
|
||||
### Final Validation
|
||||
|
||||
- **Quality Gates:** ALL PASS
|
||||
- **Story DoD:** COMPLETE
|
||||
- **Learning Extraction:** COMPLETE
|
||||
|
||||
## Files Changed
|
||||
|
||||
- {file_1} - {change_type} - {line_count} lines
|
||||
- {file_2} - {change_type} - {line_count} lines
|
||||
- {file_3} - {change_type} - {line_count} lines
|
||||
|
|
@ -185,26 +213,32 @@ Total: {file_count} files, {total_lines} lines changed
|
|||
```
|
||||
|
||||
### Step 5: Update Story File (1 minute)
|
||||
|
||||
Add commit information to story file:
|
||||
|
||||
```markdown
|
||||
## Implementation Commit
|
||||
|
||||
**Developer:** {dev_name} | **Date:** {YYYY-MM-DD} | **Commit:** {commit_hash}
|
||||
|
||||
### Commit Summary
|
||||
|
||||
- **Message:** {commit_title}
|
||||
- **Files Changed:** {file_count}
|
||||
- **Lines Changed:** {total_lines}
|
||||
- **Quality Gates:** {pass_count} PASS, {fail_count} FAIL
|
||||
|
||||
### PR Context Prepared
|
||||
|
||||
- Business summary: COMPLETE
|
||||
- Technical changes: COMPLETE
|
||||
- Technical changes: COMPLETE
|
||||
- Learning extraction: COMPLETE
|
||||
- Validation evidence: COMPLETE
|
||||
- Ready for PR creation: YES
|
||||
```
|
||||
|
||||
## Success Criteria
|
||||
|
||||
- [ ] All implementation changes committed to git
|
||||
- [ ] Commit message follows structured format with business context
|
||||
- [ ] PR context document prepared with comprehensive details
|
||||
|
|
@ -213,6 +247,7 @@ Add commit information to story file:
|
|||
- [ ] Learning items integrated into PR context
|
||||
|
||||
## Commit Message Guidelines
|
||||
|
||||
- **Title:** Concise epic-story identifier with brief summary
|
||||
- **Body:** Structured format with business and technical context
|
||||
- **Learning:** Include learning items count and key insights
|
||||
|
|
@ -220,19 +255,22 @@ Add commit information to story file:
|
|||
- **Attribution:** Standard Claude Code attribution
|
||||
|
||||
## PR Context Structure
|
||||
|
||||
- **Business-First:** Lead with business value and impact
|
||||
- **Technical-Second:** Detailed technical changes and architecture
|
||||
- **Learning-Third:** Captured learnings and future actions
|
||||
- **Evidence-Last:** Validation proof and review results
|
||||
|
||||
## Integration Points
|
||||
|
||||
- **Input from:** party-mode-learning-review (team consensus)
|
||||
- **Output to:** create-comprehensive-pr (PR generation)
|
||||
- **Handoff:** "Implementation committed. Comprehensive PR context prepared. Ready for PR creation."
|
||||
|
||||
## LLM Optimization Notes
|
||||
|
||||
- Structured commit messages enable rapid parsing
|
||||
- Token limits in PR context prevent information overload
|
||||
- Business-first ordering prioritizes stakeholder needs
|
||||
- Evidence-based validation provides objective review criteria
|
||||
- Comprehensive context reduces PR review time and questions
|
||||
- Comprehensive context reduces PR review time and questions
|
||||
|
|
|
|||
|
|
@ -1,16 +1,20 @@
|
|||
# Consolidate Review Feedback
|
||||
|
||||
## Task Overview
|
||||
|
||||
**Agent:** sm
|
||||
**Action Type:** feedback-consolidation
|
||||
**Duration:** 10-15 minutes
|
||||
**LLM-Optimized:** Token-efficient structured consolidation
|
||||
**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/SCOPE-CREEP classification for efficient implementation while maintaining story focus.
|
||||
|
||||
## Context
|
||||
|
||||
Central coordination after 5 parallel Round 1 reviews:
|
||||
|
||||
- Architecture, Business, Process, QA, UX feedback streams
|
||||
- Priority classification and conflict resolution
|
||||
- Coherent implementation roadmap generation
|
||||
|
|
@ -19,10 +23,11 @@ Central coordination after 5 parallel Round 1 reviews:
|
|||
## Inputs
|
||||
|
||||
### Required
|
||||
|
||||
- `story_file` (string): Path to the story file being reviewed
|
||||
- `architecture_feedback` (object): Results from architect review
|
||||
- `business_feedback` (object): Results from business/PO review
|
||||
- `process_feedback` (object): Results from process/SM review
|
||||
- `process_feedback` (object): Results from process/SM review
|
||||
- `qa_feedback` (object): Results from QA review
|
||||
- `ux_feedback` (object): Results from UX expert review
|
||||
|
||||
|
|
@ -37,12 +42,14 @@ 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
|
||||
- Process: DoD compliance and workflow adherence
|
||||
|
|
@ -50,6 +57,7 @@ Central coordination after 5 parallel Round 1 reviews:
|
|||
- UX: User experience and accessibility concerns
|
||||
|
||||
**Scope Assessment:**
|
||||
|
||||
```
|
||||
FEEDBACK_ANALYSIS:
|
||||
- Total items: [count]
|
||||
|
|
@ -64,6 +72,7 @@ FEEDBACK_ANALYSIS:
|
|||
|
||||
**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
|
||||
|
|
@ -73,6 +82,7 @@ Before classification, compare ALL feedback against original story acceptance cr
|
|||
- Consult architect for complex technical feasibility questions if needed
|
||||
|
||||
**REQUIRED-FOR-COMPLETION** (Blocks story completion):
|
||||
|
||||
- Acceptance criteria gaps
|
||||
- Critical functionality breaks
|
||||
- Business rule violations
|
||||
|
|
@ -80,6 +90,7 @@ Before classification, compare ALL feedback against original story acceptance cr
|
|||
- Core feature missing/incorrect
|
||||
|
||||
**QUALITY-STANDARD** (Project standard violations):
|
||||
|
||||
- Test coverage below requirements
|
||||
- Code quality standard violations
|
||||
- Performance threshold failures
|
||||
|
|
@ -88,6 +99,7 @@ Before classification, compare ALL feedback against original story acceptance cr
|
|||
- Architecture pattern violations
|
||||
|
||||
**IMPROVEMENT** (Future enhancement opportunities):
|
||||
|
||||
- Code optimization suggestions
|
||||
- UX polish improvements
|
||||
- Technical debt reduction
|
||||
|
|
@ -96,6 +108,7 @@ Before classification, compare ALL feedback against original story acceptance cr
|
|||
- 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
|
||||
|
|
@ -105,12 +118,15 @@ Before classification, compare ALL feedback against original story acceptance cr
|
|||
- "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]
|
||||
```
|
||||
|
||||
### Step 3: Conflict Resolution (2-3 minutes)
|
||||
|
||||
**Conflict Resolution Protocol:**
|
||||
|
||||
- Technical vs Business conflicts → Acceptance criteria priority
|
||||
- Similar issues → Consolidate into single action
|
||||
- Priority disputes → Story completion impact assessment
|
||||
|
|
@ -118,7 +134,9 @@ Before classification, compare ALL feedback against original story acceptance cr
|
|||
- Complex technical conflicts → Escalate to architect consultation
|
||||
|
||||
### Step 4: Implementation Sequencing (3-4 minutes)
|
||||
|
||||
**Sequencing Rules:**
|
||||
|
||||
1. SCOPE-CREEP items → IGNORE (do not implement)
|
||||
2. REQUIRED-FOR-COMPLETION (dependency order)
|
||||
3. QUALITY-STANDARD (grouped by domain)
|
||||
|
|
@ -126,6 +144,7 @@ Before classification, compare ALL feedback against original story acceptance cr
|
|||
5. Validation checkpoints after major changes
|
||||
|
||||
**Implementation Groups:**
|
||||
|
||||
```
|
||||
PHASE_1: [Critical fixes] - Est: [time]
|
||||
PHASE_2: [Quality standards] - Est: [time]
|
||||
|
|
@ -133,13 +152,16 @@ VALIDATION: [Testing approach] - Est: [time]
|
|||
```
|
||||
|
||||
### Step 5: Documentation Update (2 minutes)
|
||||
|
||||
Update story file with:
|
||||
|
||||
```markdown
|
||||
## Review Consolidation Summary
|
||||
|
||||
**Scrum Master:** [Name] | **Date:** [YYYY-MM-DD] | **Duration:** [X minutes]
|
||||
|
||||
### Round 1 Review Results
|
||||
|
||||
- Architecture: [PASS/ISSUES] ([X] items)
|
||||
- Business: [PASS/ISSUES] ([X] items)
|
||||
- Process: [PASS/ISSUES] ([X] items)
|
||||
|
|
@ -147,19 +169,25 @@ Update story file with:
|
|||
- UX: [PASS/ISSUES] ([X] items)
|
||||
|
||||
### Consolidated Actions
|
||||
|
||||
#### REQUIRED-FOR-COMPLETION ([X] items)
|
||||
|
||||
- [Issue] - [Domain] - [Effort] - [Impact] | Max 50 tokens
|
||||
|
||||
#### QUALITY-STANDARD ([X] items)
|
||||
|
||||
- [Issue] - [Domain] - [Standard] - [Effort] | Max 50 tokens
|
||||
|
||||
#### 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]
|
||||
**Validation:** [Testing approach] - Est: [time]
|
||||
|
|
@ -174,6 +202,7 @@ Update story file with:
|
|||
- Specify validation criteria for each fix
|
||||
|
||||
## Success Criteria
|
||||
|
||||
- [ ] All 5 review streams analyzed and categorized
|
||||
- [ ] Original acceptance criteria reviewed and compared against all feedback
|
||||
- [ ] Scope creep identified by Scrum Master and marked as IGNORE
|
||||
|
|
@ -195,6 +224,7 @@ Update story file with:
|
|||
## Error Handling
|
||||
|
||||
If feedback is incomplete or unclear:
|
||||
|
||||
1. Identify specific gaps in review feedback
|
||||
2. Request clarification from relevant reviewer
|
||||
3. Document assumptions made in consolidation
|
||||
|
|
@ -202,12 +232,14 @@ If feedback is incomplete or unclear:
|
|||
5. Flag uncertainties for developer attention
|
||||
|
||||
If conflicts cannot be resolved:
|
||||
|
||||
1. Escalate to Product Owner for business priority decisions
|
||||
2. Make technical recommendations based on architecture principles
|
||||
3. Document the conflict and resolution approach
|
||||
4. Ensure MVP-BLOCKING classification takes precedence
|
||||
|
||||
## LLM Optimization Notes
|
||||
|
||||
- Token limits enforce brevity and focus
|
||||
- Structured classification enables rapid scanning
|
||||
- Time estimates prevent scope creep
|
||||
|
|
@ -221,4 +253,4 @@ If conflicts cannot be resolved:
|
|||
- **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
|
||||
- **Validation:** Next phase will validate using story docs + Playwright MCP
|
||||
|
|
|
|||
|
|
@ -1,15 +1,18 @@
|
|||
# Create Comprehensive PR
|
||||
|
||||
## Task Overview
|
||||
|
||||
**Agent:** po (Product Owner - Business Context Owner)
|
||||
**Action Type:** pr-creation-with-context
|
||||
**Duration:** 5-8 minutes
|
||||
**LLM-Optimized:** Business-driven PR with comprehensive context
|
||||
**LLM-Optimized:** Business-driven PR with comprehensive context
|
||||
|
||||
## Purpose
|
||||
|
||||
Generate pull request with business summary, technical changes, learning extraction, and validation evidence for streamlined review and delivery.
|
||||
|
||||
## Inputs
|
||||
|
||||
- Story implementation file with complete context
|
||||
- Commit information and PR context from commit-and-prepare-pr
|
||||
- Learning review results and team consensus
|
||||
|
|
@ -17,6 +20,7 @@ Generate pull request with business summary, technical changes, learning extract
|
|||
- Epic completion status and retrospective context
|
||||
|
||||
## Outputs
|
||||
|
||||
- GitHub PR created with comprehensive description
|
||||
- PR linked to story and epic context
|
||||
- Review assignments based on learning items
|
||||
|
|
@ -25,6 +29,7 @@ Generate pull request with business summary, technical changes, learning extract
|
|||
## Execution Steps
|
||||
|
||||
### Step 1: Generate PR Title (1 minute)
|
||||
|
||||
```
|
||||
PR_TITLE_FORMAT:
|
||||
[Epic{epic_number}.{story_number}] {business_focused_title}
|
||||
|
|
@ -36,12 +41,14 @@ Examples:
|
|||
```
|
||||
|
||||
### Step 2: Create PR Description (4-6 minutes)
|
||||
|
||||
Generate comprehensive PR description:
|
||||
|
||||
```markdown
|
||||
# Epic {epic_number}.{story_number}: {story_title}
|
||||
|
||||
## 🎯 Business Summary
|
||||
|
||||
**Epic:** {epic_title}
|
||||
**Epic Progress:** {epic_completion_percentage}% complete ({completed_stories}/{total_stories} stories)
|
||||
**Business Value:** {primary_business_value}
|
||||
|
|
@ -50,21 +57,25 @@ Generate comprehensive PR description:
|
|||
**Epic Status:** {IN_PROGRESS/COMPLETE}
|
||||
|
||||
### Key Business Outcomes
|
||||
|
||||
- ✅ {business_outcome_1}
|
||||
- ✅ {business_outcome_2}
|
||||
- ✅ {business_outcome_2}
|
||||
- ✅ {business_outcome_3}
|
||||
|
||||
## 🔧 Technical Changes
|
||||
|
||||
**Type:** {feature/enhancement/fix/refactor}
|
||||
**Complexity:** {SIMPLE/MODERATE/COMPLEX}
|
||||
**Architecture Impact:** {HIGH/MEDIUM/LOW/NONE}
|
||||
|
||||
### Implementation Summary
|
||||
|
||||
- **{component_1}:** {change_description} | Impact: {HIGH/MEDIUM/LOW}
|
||||
- **{component_2}:** {change_description} | Impact: {HIGH/MEDIUM/LOW}
|
||||
- **{component_3}:** {change_description} | Impact: {HIGH/MEDIUM/LOW}
|
||||
|
||||
### Files Changed
|
||||
|
||||
- `{file_1}` - {change_type} ({line_count} lines)
|
||||
- `{file_2}` - {change_type} ({line_count} lines)
|
||||
- `{file_3}` - {change_type} ({line_count} lines)
|
||||
|
|
@ -74,36 +85,43 @@ Generate comprehensive PR description:
|
|||
## 📚 Learning Extraction & Actions
|
||||
|
||||
### 🚨 Immediate Actions (Current Sprint)
|
||||
|
||||
- [ ] **{urgent_action_1}** - @{owner} - Due: {date}
|
||||
- [ ] **{urgent_action_2}** - @{owner} - Due: {date}
|
||||
|
||||
### 📋 Next Sprint Integration
|
||||
|
||||
- [ ] **{next_action_1}** - @{owner} - Sprint Planning Item
|
||||
- [ ] **{next_action_2}** - @{owner} - Sprint Planning Item
|
||||
|
||||
### 🚀 Future Epic Candidates
|
||||
|
||||
- **{epic_candidate_1}** - Priority: {HIGH/MEDIUM/LOW} - Est: {effort}
|
||||
- **{epic_candidate_2}** - Priority: {HIGH/MEDIUM/LOW} - Est: {effort}
|
||||
|
||||
### 🎉 Epic Completion Status
|
||||
|
||||
**Epic Progress:** {epic_completion_percentage}% complete
|
||||
**Epic Retrospective:** {TRIGGERED/PENDING}
|
||||
{epic_completion_section}
|
||||
|
||||
### 🔧 Architecture Improvements
|
||||
|
||||
- **{arch_improvement_1}** - Timeline: {current/next/backlog}
|
||||
- **{arch_improvement_2}** - Timeline: {current/next/backlog}
|
||||
|
||||
## ✅ Validation Evidence
|
||||
|
||||
### Quality Gates
|
||||
|
||||
- **Tests:** {test_count} added, {test_coverage}% coverage
|
||||
- **Linting:** ✅ PASS
|
||||
- **Type Safety:** ✅ PASS
|
||||
- **Type Safety:** ✅ PASS
|
||||
- **Build:** ✅ PASS
|
||||
- **E2E Tests:** ✅ PASS ({test_count} scenarios)
|
||||
|
||||
### Review Process
|
||||
|
||||
- **Pre-Review Validation:** ✅ COMPLETE
|
||||
- **Round 1 Reviews:** ✅ COMPLETE ({review_count} reviewers)
|
||||
- **Feedback Consolidation:** ✅ COMPLETE ({feedback_items} items)
|
||||
|
|
@ -111,6 +129,7 @@ Generate comprehensive PR description:
|
|||
- **Final Validation:** ✅ COMPLETE
|
||||
|
||||
### Story DoD Compliance
|
||||
|
||||
- **Business Requirements:** ✅ MET
|
||||
- **Technical Requirements:** ✅ MET
|
||||
- **Quality Standards:** ✅ MET
|
||||
|
|
@ -120,38 +139,44 @@ Generate comprehensive PR description:
|
|||
## 🔍 Test Coverage & Scenarios
|
||||
|
||||
### New Tests Added
|
||||
|
||||
- `{test_file_1}` - {test_count} tests - {coverage_area}
|
||||
- `{test_file_2}` - {test_count} tests - {coverage_area}
|
||||
|
||||
### E2E Scenarios Covered
|
||||
|
||||
- ✅ {scenario_1} - PASS
|
||||
- ✅ {scenario_2} - PASS
|
||||
- ✅ {scenario_2} - PASS
|
||||
- ✅ {scenario_3} - PASS
|
||||
|
||||
### Edge Cases Tested
|
||||
|
||||
- ✅ {edge_case_1} - PASS
|
||||
- ✅ {edge_case_2} - PASS
|
||||
|
||||
## 📖 Documentation Updates
|
||||
|
||||
- **Story File:** Updated with complete implementation context
|
||||
- **Epic Progress:** Updated with story completion
|
||||
- **Architecture Docs:** {updated/not_applicable}
|
||||
- **API Documentation:** {updated/not_applicable}
|
||||
- **API Documentation:** {updated/not_applicable}
|
||||
- **User Documentation:** {updated/not_applicable}
|
||||
- **Epic Retrospective:** {SCHEDULED/NOT_APPLICABLE}
|
||||
|
||||
## 🔗 Related Links
|
||||
|
||||
- **Epic:** [Epic {epic_number}](../prd/epic{epic_number}.md)
|
||||
- **Story:** [Story {epic_number}.{story_number}](../stories/epic{epic_number}.story{story_number}.story.md)
|
||||
- **Commit:** {commit_hash}
|
||||
|
||||
---
|
||||
|
||||
**Story Status:** Done → Ready for Delivery
|
||||
**Epic Status:** {epic_completion_percentage}% complete
|
||||
**Epic Retrospective:** {TRIGGERED/PENDING}
|
||||
**Implementation Time:** {actual_time} (Est: {estimated_time})
|
||||
**Quality Score:** {quality_score}/10
|
||||
**Learning Items:** {learning_count} captured
|
||||
**Learning Items:** {learning_count} captured
|
||||
|
||||
{epic_completion_celebration}
|
||||
|
||||
|
|
@ -159,6 +184,7 @@ Generate comprehensive PR description:
|
|||
```
|
||||
|
||||
### Step 3: Create PR with GitHub CLI (1-2 minutes)
|
||||
|
||||
```bash
|
||||
gh pr create --title "[Epic{epic_number}.Story{story_number}] {business_title}" --body "$(cat <<'EOF'
|
||||
{comprehensive_pr_description_from_step_2}
|
||||
|
|
@ -167,30 +193,35 @@ EOF
|
|||
```
|
||||
|
||||
### Step 4: Assign Reviewers Based on Learning Items (1 minute)
|
||||
|
||||
```bash
|
||||
# Auto-assign reviewers based on learning categories
|
||||
gh pr edit --add-reviewer {architect_username} # For ARCH_CHANGE items
|
||||
gh pr edit --add-reviewer {po_username} # For FUTURE_EPIC items
|
||||
gh pr edit --add-reviewer {po_username} # For FUTURE_EPIC items
|
||||
gh pr edit --add-reviewer {dev_team_username} # For URGENT_FIX items
|
||||
gh pr edit --add-reviewer {sm_username} # For PROCESS_IMPROVEMENT items
|
||||
```
|
||||
|
||||
### Step 5: Update Story File with PR Information (1 minute)
|
||||
|
||||
```markdown
|
||||
## Pull Request Created
|
||||
|
||||
**PO:** {po_name} | **Date:** {YYYY-MM-DD} | **PR:** #{pr_number}
|
||||
|
||||
### PR Details
|
||||
|
||||
- **Title:** [Epic{epic_number}.Story{story_number}] {business_title}
|
||||
- **URL:** {pr_url}
|
||||
- **Reviewers:** {reviewer_list}
|
||||
- **Status:** Open → Ready for Review
|
||||
|
||||
### PR Content Summary
|
||||
|
||||
- Business summary: ✅ COMPLETE
|
||||
- Epic completion status: ✅ COMPLETE
|
||||
- Technical changes: ✅ COMPLETE
|
||||
- Learning extraction: ✅ COMPLETE
|
||||
- Learning extraction: ✅ COMPLETE
|
||||
- Validation evidence: ✅ COMPLETE
|
||||
- Review assignments: ✅ COMPLETE
|
||||
- Epic retrospective context: ✅ COMPLETE (MANDATORY if epic 100% complete)
|
||||
|
|
@ -200,6 +231,7 @@ gh pr edit --add-reviewer {sm_username} # For PROCESS_IMPROVEMENT items
|
|||
```
|
||||
|
||||
## Success Criteria
|
||||
|
||||
- [ ] PR created with comprehensive business and technical context
|
||||
- [ ] Epic completion status prominently displayed
|
||||
- [ ] Epic retrospective context included (if triggered)
|
||||
|
|
@ -210,6 +242,7 @@ gh pr edit --add-reviewer {sm_username} # For PROCESS_IMPROVEMENT items
|
|||
- [ ] PR ready for efficient review and merge
|
||||
|
||||
## PR Description Guidelines
|
||||
|
||||
- **Business-First:** Lead with business value and user impact
|
||||
- **Epic-Context:** Prominently display epic completion status
|
||||
- **Learning-Prominent:** Highlight learnings and future actions
|
||||
|
|
@ -219,25 +252,28 @@ gh pr edit --add-reviewer {sm_username} # For PROCESS_IMPROVEMENT items
|
|||
- **Celebration:** Highlight epic completion if applicable
|
||||
|
||||
## Reviewer Assignment Logic
|
||||
|
||||
```
|
||||
REVIEWER_MAPPING:
|
||||
- ARCH_CHANGE items → @architect (technical review)
|
||||
- FUTURE_EPIC items → @po (business validation)
|
||||
- URGENT_FIX items → @dev-team (technical validation)
|
||||
- URGENT_FIX items → @dev-team (technical validation)
|
||||
- PROCESS_IMPROVEMENT → @sm (process review)
|
||||
- TOOLING items → @infra-devops (infrastructure review)
|
||||
- KNOWLEDGE_GAP → @sm + @po (team development)
|
||||
```
|
||||
|
||||
## Integration Points
|
||||
|
||||
- **Input from:** commit-and-prepare-pr (commit and context)
|
||||
- **Output to:** update-epic-progress (epic tracking)
|
||||
- **Handoff:** "PR created and ready for review. Epic progress tracking initiated."
|
||||
|
||||
## LLM Optimization Notes
|
||||
|
||||
- Business-first structure prioritizes stakeholder understanding
|
||||
- Learning extraction prevents knowledge loss
|
||||
- Evidence-based validation reduces review overhead
|
||||
- Action-oriented format drives immediate value
|
||||
- Comprehensive context enables faster review cycles
|
||||
- Token-efficient format maintains readability while providing complete information
|
||||
- Token-efficient format maintains readability while providing complete information
|
||||
|
|
|
|||
|
|
@ -1,16 +1,19 @@
|
|||
# Epic Party Mode Retrospective
|
||||
|
||||
## Task Overview
|
||||
|
||||
**Agent:** sm (Scrum Master - Epic Retrospective Facilitator and Strategic Documenter)
|
||||
**Action Type:** multi-agent-epic-retrospective
|
||||
**Duration:** 45-60 minutes
|
||||
**Collaborators:** [architect, po, dev, ux-expert] as participants
|
||||
**LLM-Optimized:** Multi-agent collaborative epic insight generation
|
||||
**LLM-Optimized:** Multi-agent collaborative epic insight generation
|
||||
|
||||
## Purpose
|
||||
|
||||
Conduct comprehensive epic retrospective with all key stakeholders to consolidate learnings from ALL stories, generate epic-level insights and patterns, create action items for next epic, and build team consensus on strategic improvements.
|
||||
|
||||
## Inputs
|
||||
|
||||
- Epic file with 100% completion status
|
||||
- All completed story files from the epic
|
||||
- Consolidated learning items from all stories
|
||||
|
|
@ -18,6 +21,7 @@ Conduct comprehensive epic retrospective with all key stakeholders to consolidat
|
|||
- Quality scores and velocity trends
|
||||
|
||||
## Outputs
|
||||
|
||||
- Epic retrospective summary with consolidated insights
|
||||
- Epic-level patterns and strategic learnings
|
||||
- Action items for next epic with ownership
|
||||
|
|
@ -25,6 +29,7 @@ Conduct comprehensive epic retrospective with all key stakeholders to consolidat
|
|||
- Epic completion artifacts and knowledge base
|
||||
|
||||
## Multi-Agent Participants
|
||||
|
||||
- **sm** (Scrum Master) - Epic retrospective facilitator and strategic documentation owner
|
||||
- **architect** (Technical Architect) - Technical patterns and architecture insights
|
||||
- **po** (Product Owner) - Business patterns and value optimization
|
||||
|
|
@ -34,6 +39,7 @@ Conduct comprehensive epic retrospective with all key stakeholders to consolidat
|
|||
## Execution Steps
|
||||
|
||||
### Step 1: Epic Data Consolidation (10 minutes)
|
||||
|
||||
**Agent:** sm (Epic Retrospective Facilitator)
|
||||
Lead epic data consolidation with strategic focus on process insights:
|
||||
|
||||
|
|
@ -41,12 +47,14 @@ Lead epic data consolidation with strategic focus on process insights:
|
|||
# Epic {epic_number} Retrospective Data
|
||||
|
||||
## Epic Overview
|
||||
|
||||
- **Epic Title:** {epic_title}
|
||||
- **Duration:** {start_date} to {completion_date} ({total_days} days)
|
||||
- **Stories Completed:** {story_count}
|
||||
- **Team Members:** {team_member_list}
|
||||
|
||||
## Epic Metrics Summary
|
||||
|
||||
- **Total Story Points:** {total_story_points}
|
||||
- **Velocity:** {average_velocity} points/sprint
|
||||
- **Quality Score:** {average_quality_score}/10
|
||||
|
|
@ -54,117 +62,150 @@ Lead epic data consolidation with strategic focus on process insights:
|
|||
- **Fix Cycles:** {average_fix_cycles}
|
||||
|
||||
## Learning Items by Category
|
||||
|
||||
### ARCH_CHANGE ({arch_count} items)
|
||||
|
||||
- {arch_item_1} | Stories: {story_list} | Priority: {HIGH/MEDIUM/LOW}
|
||||
- {arch_item_2} | Stories: {story_list} | Priority: {HIGH/MEDIUM/LOW}
|
||||
|
||||
### FUTURE_EPIC ({future_count} items)
|
||||
### FUTURE_EPIC ({future_count} items)
|
||||
|
||||
- {future_item_1} | Stories: {story_list} | Est: {effort_estimate}
|
||||
- {future_item_2} | Stories: {story_list} | Est: {effort_estimate}
|
||||
|
||||
### URGENT_FIX ({urgent_count} items)
|
||||
|
||||
- {urgent_item_1} | Stories: {story_list} | Criticality: {HIGH/MEDIUM/LOW}
|
||||
- {urgent_item_2} | Stories: {story_list} | Criticality: {HIGH/MEDIUM/LOW}
|
||||
|
||||
### PROCESS_IMPROVEMENT ({process_count} items)
|
||||
|
||||
- {process_item_1} | Stories: {story_list} | Impact: {HIGH/MEDIUM/LOW}
|
||||
- {process_item_2} | Stories: {story_list} | Impact: {HIGH/MEDIUM/LOW}
|
||||
|
||||
### TOOLING ({tooling_count} items)
|
||||
|
||||
- {tooling_item_1} | Stories: {story_list} | Complexity: {HIGH/MEDIUM/LOW}
|
||||
- {tooling_item_2} | Stories: {story_list} | Complexity: {HIGH/MEDIUM/LOW}
|
||||
|
||||
### KNOWLEDGE_GAP ({knowledge_count} items)
|
||||
|
||||
- {knowledge_item_1} | Stories: {story_list} | Training: {needed/available}
|
||||
- {knowledge_item_2} | Stories: {story_list} | Training: {needed/available}
|
||||
```
|
||||
|
||||
### Step 2: Multi-Agent Pattern Analysis (15 minutes)
|
||||
|
||||
**Agents:** architect, po, dev, ux-expert (in parallel)
|
||||
|
||||
#### Architect Analysis
|
||||
|
||||
```markdown
|
||||
## Technical Patterns Identified
|
||||
|
||||
### Positive Patterns
|
||||
|
||||
- **{pattern_1}:** Appeared in {story_count} stories | Impact: {impact_description}
|
||||
- **{pattern_2}:** Appeared in {story_count} stories | Impact: {impact_description}
|
||||
|
||||
### Negative Patterns
|
||||
### Negative Patterns
|
||||
|
||||
- **{anti_pattern_1}:** Appeared in {story_count} stories | Risk: {risk_description}
|
||||
- **{anti_pattern_2}:** Appeared in {story_count} stories | Risk: {risk_description}
|
||||
|
||||
### Architecture Evolution
|
||||
|
||||
- **Debt Accumulated:** {debt_items} items requiring attention
|
||||
- **Quality Improvements:** {improvement_items} implemented
|
||||
- **Technical Decisions:** {decision_count} major decisions made
|
||||
```
|
||||
|
||||
#### Product Owner Analysis
|
||||
|
||||
```markdown
|
||||
## Business Value Patterns
|
||||
|
||||
### Value Delivery Patterns
|
||||
|
||||
- **{value_pattern_1}:** Generated {business_impact} | Stories: {story_list}
|
||||
- **{value_pattern_2}:** Generated {business_impact} | Stories: {story_list}
|
||||
|
||||
### User Impact Patterns
|
||||
|
||||
- **{user_pattern_1}:** Affected {user_count} users | Feedback: {feedback_summary}
|
||||
- **{user_pattern_2}:** Affected {user_count} users | Feedback: {feedback_summary}
|
||||
|
||||
### Business Learning
|
||||
|
||||
- **Market Response:** {response_summary}
|
||||
- **Feature Adoption:** {adoption_metrics}
|
||||
- **Value Realization:** {actual_vs_expected}
|
||||
```
|
||||
|
||||
#### Developer Analysis
|
||||
|
||||
```markdown
|
||||
## Implementation Patterns
|
||||
## Implementation Patterns
|
||||
|
||||
### Efficiency Patterns
|
||||
|
||||
- **{efficiency_pattern_1}:** Reduced effort by {time_saved} | Stories: {story_list}
|
||||
- **{efficiency_pattern_2}:** Increased effort by {time_added} | Stories: {story_list}
|
||||
|
||||
### Quality Patterns
|
||||
|
||||
- **{quality_pattern_1}:** Improved quality score by {score_improvement} | Stories: {story_list}
|
||||
- **{quality_pattern_2}:** Required {fix_cycles} fix cycles | Stories: {story_list}
|
||||
|
||||
### Technical Debt Impact
|
||||
|
||||
- **Debt Created:** {new_debt_items} items
|
||||
- **Debt Resolved:** {resolved_debt_items} items
|
||||
- **Net Debt Change:** {net_change}
|
||||
```
|
||||
|
||||
#### UX Expert Analysis
|
||||
|
||||
```markdown
|
||||
## User Experience Patterns
|
||||
|
||||
### UX Success Patterns
|
||||
|
||||
- **{ux_pattern_1}:** Enhanced {ux_metric} by {improvement} | Stories: {story_list}
|
||||
- **{ux_pattern_2}:** Improved {ux_metric} by {improvement} | Stories: {story_list}
|
||||
|
||||
### UX Challenge Patterns
|
||||
|
||||
- **{challenge_1}:** Required {iteration_count} iterations | Stories: {story_list}
|
||||
- **{challenge_2}:** Needed {additional_effort} extra effort | Stories: {story_list}
|
||||
|
||||
### Design System Evolution
|
||||
|
||||
- **Components Added:** {component_count}
|
||||
- **Patterns Established:** {pattern_count}
|
||||
- **Accessibility Improvements:** {a11y_count}
|
||||
```
|
||||
|
||||
### Step 3: Party Mode Consensus Building (15 minutes)
|
||||
|
||||
**Facilitator:** sm (Epic Strategic Leader)
|
||||
**Participants:** All agents (architect, po, dev, ux-expert as collaborators)
|
||||
|
||||
#### Epic-Level Insights Voting
|
||||
|
||||
```markdown
|
||||
## Epic Insights Consensus (Party Mode)
|
||||
|
||||
### Top 3 Epic Success Factors (Team Consensus)
|
||||
|
||||
1. **{success_factor_1}** | Votes: {vote_count}/5 | Priority: {HIGH/MEDIUM/LOW}
|
||||
|
||||
- Evidence: {supporting_evidence}
|
||||
- Stories: {story_references}
|
||||
|
||||
2. **{success_factor_2}** | Votes: {vote_count}/5 | Priority: {HIGH/MEDIUM/LOW}
|
||||
- Evidence: {supporting_evidence}
|
||||
|
||||
- Evidence: {supporting_evidence}
|
||||
- Stories: {story_references}
|
||||
|
||||
3. **{success_factor_3}** | Votes: {vote_count}/5 | Priority: {HIGH/MEDIUM/LOW}
|
||||
|
|
@ -172,11 +213,14 @@ Lead epic data consolidation with strategic focus on process insights:
|
|||
- Stories: {story_references}
|
||||
|
||||
### Top 3 Epic Improvement Areas (Team Consensus)
|
||||
|
||||
1. **{improvement_1}** | Votes: {vote_count}/5 | Impact: {HIGH/MEDIUM/LOW}
|
||||
|
||||
- Root Cause: {cause_analysis}
|
||||
- Stories Affected: {story_references}
|
||||
|
||||
2. **{improvement_2}** | Votes: {vote_count}/5 | Impact: {HIGH/MEDIUM/LOW}
|
||||
|
||||
- Root Cause: {cause_analysis}
|
||||
- Stories Affected: {story_references}
|
||||
|
||||
|
|
@ -186,52 +230,63 @@ Lead epic data consolidation with strategic focus on process insights:
|
|||
```
|
||||
|
||||
#### Future Epic Prioritization
|
||||
|
||||
```markdown
|
||||
### Next Epic Action Items (Consensus)
|
||||
|
||||
#### Immediate Actions (Next Sprint)
|
||||
|
||||
- [ ] **{action_1}** | Owner: @{agent} | Due: {date} | Votes: {vote_count}/5
|
||||
- [ ] **{action_2}** | Owner: @{agent} | Due: {date} | Votes: {vote_count}/5
|
||||
- [ ] **{action_3}** | Owner: @{agent} | Due: {date} | Votes: {vote_count}/5
|
||||
|
||||
#### Next Epic Preparation
|
||||
|
||||
- [ ] **{prep_action_1}** | Owner: @{agent} | Timeline: {timeframe} | Priority: {HIGH/MEDIUM/LOW}
|
||||
- [ ] **{prep_action_2}** | Owner: @{agent} | Timeline: {timeframe} | Priority: {HIGH/MEDIUM/LOW}
|
||||
- [ ] **{prep_action_3}** | Owner: @{agent} | Timeline: {timeframe} | Priority: {HIGH/MEDIUM/LOW}
|
||||
|
||||
#### Strategic Improvements
|
||||
|
||||
- [ ] **{strategic_1}** | Owner: @{agent} | Timeline: {timeframe} | Impact: {HIGH/MEDIUM/LOW}
|
||||
- [ ] **{strategic_2}** | Owner: @{agent} | Timeline: {timeframe} | Impact: {HIGH/MEDIUM/LOW}
|
||||
```
|
||||
|
||||
### Step 4: Epic Knowledge Consolidation (10 minutes)
|
||||
|
||||
**Agent:** sm (Strategic Documentation Owner) with input validation from all agents
|
||||
|
||||
```markdown
|
||||
## Epic {epic_number} Knowledge Base
|
||||
|
||||
### Epic Completion Summary
|
||||
|
||||
- **Business Value Delivered:** {value_score}/10
|
||||
- **Technical Quality Achieved:** {quality_score}/10
|
||||
- **Team Performance:** {performance_score}/10
|
||||
- **Process Efficiency:** {efficiency_score}/10
|
||||
|
||||
### Critical Success Patterns (Apply to Future Epics)
|
||||
|
||||
1. **{critical_pattern_1}** | Impact: {quantified_impact} | Replication: {replication_guide}
|
||||
2. **{critical_pattern_2}** | Impact: {quantified_impact} | Replication: {replication_guide}
|
||||
3. **{critical_pattern_3}** | Impact: {quantified_impact} | Replication: {replication_guide}
|
||||
|
||||
### Critical Anti-Patterns (Avoid in Future Epics)
|
||||
|
||||
1. **{anti_pattern_1}** | Cost: {quantified_cost} | Prevention: {prevention_guide}
|
||||
2. **{anti_pattern_2}** | Cost: {quantified_cost} | Prevention: {prevention_guide}
|
||||
3. **{anti_pattern_3}** | Cost: {quantified_cost} | Prevention: {prevention_guide}
|
||||
|
||||
### Epic Legacy Items
|
||||
|
||||
- **Architecture Improvements:** {arch_count} improvements implemented
|
||||
- **Process Innovations:** {process_count} new processes established
|
||||
- **Process Innovations:** {process_count} new processes established
|
||||
- **Tool Enhancements:** {tool_count} tools improved/added
|
||||
- **Team Capabilities:** {capability_count} new capabilities developed
|
||||
|
||||
### Knowledge Transfer Requirements
|
||||
|
||||
- **Documentation:** {doc_items} items need documentation
|
||||
- **Training:** {training_items} items need team training
|
||||
- **Best Practices:** {practice_items} practices need codification
|
||||
|
|
@ -239,6 +294,7 @@ Lead epic data consolidation with strategic focus on process insights:
|
|||
```
|
||||
|
||||
### Step 5: Epic Retrospective Artifacts (5 minutes)
|
||||
|
||||
**Agent:** sm (Strategic Documentation Owner)
|
||||
|
||||
Generate final epic retrospective artifacts:
|
||||
|
|
@ -247,32 +303,40 @@ Generate final epic retrospective artifacts:
|
|||
# Epic {epic_number} Retrospective Summary
|
||||
|
||||
## Epic Completion Metrics
|
||||
|
||||
- **Duration:** {total_days} days | **Target:** {target_days} days | **Variance:** {variance}
|
||||
- **Stories:** {story_count} completed | **Quality:** {avg_quality}/10 | **Velocity:** {avg_velocity}
|
||||
- **Learning Items:** {total_learning} captured | **Actions:** {action_count} defined
|
||||
|
||||
## Strategic Insights for Next Epic
|
||||
|
||||
### What Worked Well (Replicate)
|
||||
|
||||
- {insight_1}
|
||||
- {insight_2}
|
||||
- {insight_2}
|
||||
- {insight_3}
|
||||
|
||||
### What Didn't Work (Avoid)
|
||||
|
||||
- {insight_1}
|
||||
- {insight_2}
|
||||
- {insight_3}
|
||||
|
||||
### What to Try (Experiment)
|
||||
|
||||
- {experiment_1}
|
||||
- {experiment_2}
|
||||
- {experiment_3}
|
||||
|
||||
## Action Items for Next Epic
|
||||
|
||||
### Immediate (Next Sprint)
|
||||
|
||||
- {immediate_action_1} - @{owner} - Due: {date}
|
||||
- {immediate_action_2} - @{owner} - Due: {date}
|
||||
|
||||
### Strategic (Next Epic)
|
||||
|
||||
- {strategic_action_1} - @{owner} - Timeline: {timeframe}
|
||||
- {strategic_action_2} - @{owner} - Timeline: {timeframe}
|
||||
|
||||
|
|
@ -282,6 +346,7 @@ Generate final epic retrospective artifacts:
|
|||
```
|
||||
|
||||
## Success Criteria
|
||||
|
||||
- [ ] All story learnings consolidated at epic level
|
||||
- [ ] Multi-agent pattern analysis completed by all stakeholders
|
||||
- [ ] Team consensus achieved on top insights and improvements
|
||||
|
|
@ -290,6 +355,7 @@ Generate final epic retrospective artifacts:
|
|||
- [ ] Next epic preparation actions identified and assigned
|
||||
|
||||
## Party Mode Consensus Protocol
|
||||
|
||||
- **Voting:** Each agent votes on insights (1-5 scale)
|
||||
- **Consensus Threshold:** 60% agreement (3/5 agents)
|
||||
- **Conflict Resolution:** SM facilitates strategic discussion until consensus with focus on epic-level process insights
|
||||
|
|
@ -297,20 +363,23 @@ Generate final epic retrospective artifacts:
|
|||
- **Documentation:** All decisions recorded with rationale
|
||||
|
||||
## Epic Retrospective Triggers
|
||||
|
||||
- **Automatic:** Triggered when epic progress reaches 100%
|
||||
- **Manual Override:** SM can trigger early if needed
|
||||
- **Prerequisites:** All stories must be "Done - Delivered" status
|
||||
- **Dependencies:** Final story PR must be created
|
||||
|
||||
## Integration Points
|
||||
|
||||
- **Input from:** update-epic-progress (100% completion detected)
|
||||
- **Output to:** Next epic planning and story-implementation workflow
|
||||
- **Handoff:** "SM-led epic retrospective complete. Strategic process insights documented. Epic-level patterns identified. Next epic preparation initiated with SM oversight."
|
||||
|
||||
## LLM Optimization Notes
|
||||
|
||||
- Multi-agent parallel analysis maximizes perspective diversity
|
||||
- Structured voting enables objective consensus building
|
||||
- Time-boxed sessions prevent analysis paralysis
|
||||
- Action-oriented outputs drive immediate value
|
||||
- Knowledge base format enables future epic reference
|
||||
- Token-efficient format maintains comprehensive coverage without overwhelming detail
|
||||
- Token-efficient format maintains comprehensive coverage without overwhelming detail
|
||||
|
|
|
|||
|
|
@ -1,16 +1,20 @@
|
|||
# Implement Consolidated Fixes
|
||||
|
||||
## Task Overview
|
||||
|
||||
**Agent:** dev
|
||||
**Action Type:** fix-implementation
|
||||
**Duration:** 15-45 minutes (varies by fix count)
|
||||
**LLM-Optimized:** Systematic fix implementation with evidence tracking
|
||||
**LLM-Optimized:** Systematic fix implementation with evidence tracking
|
||||
|
||||
## Purpose
|
||||
|
||||
Implement consolidated fixes focusing on REQUIRED-FOR-COMPLETION and QUALITY-STANDARD items with clear documentation for validation.
|
||||
|
||||
## Context
|
||||
|
||||
Systematic implementation of prioritized review feedback:
|
||||
|
||||
- REQUIRED-FOR-COMPLETION and QUALITY-STANDARD priority focus
|
||||
- Implementation plan sequencing for efficiency
|
||||
- Clear documentation for validation evidence
|
||||
|
|
@ -19,6 +23,7 @@ Systematic implementation of prioritized review feedback:
|
|||
## Inputs
|
||||
|
||||
### Required
|
||||
|
||||
- `story_file` (string): Path to the story file with consolidation summary
|
||||
- `consolidated_feedback` (object): Prioritized feedback from consolidation task
|
||||
|
||||
|
|
@ -33,6 +38,7 @@ Systematic implementation of prioritized review feedback:
|
|||
### Step 1: Pre-Implementation Analysis (3-5 minutes)
|
||||
|
||||
**Consolidation Review:**
|
||||
|
||||
```
|
||||
FIX_ANALYSIS:
|
||||
- REQUIRED items: [count]
|
||||
|
|
@ -43,6 +49,7 @@ FIX_ANALYSIS:
|
|||
```
|
||||
|
||||
**Technical Scope Assessment:**
|
||||
|
||||
- Backend changes: [YES/NO] - [component list]
|
||||
- Frontend changes: [YES/NO] - [component list]
|
||||
- Integration points: [list]
|
||||
|
|
@ -52,12 +59,14 @@ FIX_ANALYSIS:
|
|||
### Step 2: Systematic Fix Implementation (10-35 minutes)
|
||||
|
||||
**Implementation Protocol:**
|
||||
|
||||
1. Phase 1: REQUIRED-FOR-COMPLETION fixes (sequential)
|
||||
2. Phase 2: QUALITY-STANDARD fixes (grouped by domain)
|
||||
3. Continuous quality gate validation
|
||||
4. Evidence documentation per fix
|
||||
|
||||
**Per-Fix Process:**
|
||||
|
||||
```
|
||||
[FIX_ID]: [Description] - [Domain]
|
||||
Implementation: [Code changes made]
|
||||
|
|
@ -65,40 +74,46 @@ Validation: [How verified]
|
|||
Quality Gates: [PASS/FAIL status]
|
||||
Evidence: [Test results/screenshots]
|
||||
```
|
||||
|
||||
**Follow implementation plan sequence:**
|
||||
- Work through fixes in the order specified by consolidation
|
||||
- Complete each phase before moving to next
|
||||
- Test each significant change before proceeding
|
||||
- Maintain project quality gates throughout
|
||||
|
||||
**For each fix:**
|
||||
- Read the specific feedback requirement
|
||||
- Implement the change following project coding standards
|
||||
- Test the change in isolation where possible
|
||||
- Document what was changed and how
|
||||
**Follow implementation plan sequence:**
|
||||
|
||||
- Work through fixes in the order specified by consolidation
|
||||
- Complete each phase before moving to next
|
||||
- Test each significant change before proceeding
|
||||
- Maintain project quality gates throughout
|
||||
|
||||
**For each fix:**
|
||||
|
||||
- Read the specific feedback requirement
|
||||
- Implement the change following project coding standards
|
||||
- Test the change in isolation where possible
|
||||
- Document what was changed and how
|
||||
|
||||
4. **Handle different types of fixes**
|
||||
|
||||
**Architecture fixes:**
|
||||
|
||||
- Code structure improvements
|
||||
- Security enhancements
|
||||
- Performance optimizations
|
||||
- Technical debt reduction
|
||||
|
||||
**Business fixes:**
|
||||
|
||||
- Acceptance criteria adjustments
|
||||
- Business rule corrections
|
||||
- User journey improvements
|
||||
- Data validation enhancements
|
||||
|
||||
**Quality fixes:**
|
||||
|
||||
- Test coverage improvements
|
||||
- Code quality enhancements
|
||||
- Error handling additions
|
||||
- Documentation updates
|
||||
|
||||
**UX fixes:**
|
||||
|
||||
- Interface adjustments
|
||||
- Accessibility improvements
|
||||
- User interaction enhancements
|
||||
|
|
@ -107,70 +122,80 @@ Evidence: [Test results/screenshots]
|
|||
### Quality Validation
|
||||
|
||||
5. **Ensure continuous quality**
|
||||
|
||||
- Run project quality gates after significant changes
|
||||
- Verify existing functionality still works
|
||||
- Test new/modified functionality thoroughly
|
||||
- Maintain test coverage standards
|
||||
|
||||
6. **Document implementation thoroughly**
|
||||
|
||||
|
||||
**Update story file with implementation details:**
|
||||
|
||||
```markdown
|
||||
## Round 1 Fixes Implementation
|
||||
|
||||
|
||||
### REQUIRED-FOR-COMPLETION Fixes Applied
|
||||
|
||||
|
||||
#### Architecture Fixes
|
||||
|
||||
1. **[Fix Description]**
|
||||
- **Issue**: [Original feedback]
|
||||
- **Solution**: [What was implemented]
|
||||
- **Files Changed**: [List of modified files]
|
||||
- **Testing**: [How it was validated]
|
||||
|
||||
#### Business Fixes
|
||||
|
||||
#### Business Fixes
|
||||
|
||||
1. **[Fix Description]**
|
||||
- **Issue**: [Original feedback]
|
||||
- **Solution**: [What was implemented]
|
||||
- **AC Impact**: [Which acceptance criteria affected]
|
||||
- **Testing**: [How it was validated]
|
||||
|
||||
|
||||
### QUALITY-STANDARD Fixes Applied
|
||||
|
||||
|
||||
#### Process/Standards Fixes
|
||||
|
||||
1. **[Fix Description]**
|
||||
- **Issue**: [Original feedback]
|
||||
- **Standard**: [Which project standard was violated]
|
||||
- **Solution**: [What was implemented]
|
||||
- **Testing**: [How it was validated]
|
||||
|
||||
|
||||
#### Quality Fixes
|
||||
|
||||
1. **[Fix Description]**
|
||||
- **Issue**: [Original feedback]
|
||||
- **Standard**: [Test coverage/Code quality/Performance/etc.]
|
||||
- **Solution**: [What was implemented]
|
||||
- **Testing**: [How it was validated]
|
||||
|
||||
|
||||
#### UX Fixes
|
||||
|
||||
1. **[Fix Description]**
|
||||
- **Issue**: [Original feedback]
|
||||
- **Standard**: [Accessibility/Design consistency/etc.]
|
||||
- **Solution**: [What was implemented]
|
||||
- **Visual Changes**: [Description of UI changes]
|
||||
- **Testing**: [How it was validated - note if Playwright needed]
|
||||
|
||||
|
||||
### Implementation Status
|
||||
|
||||
- **REQUIRED-FOR-COMPLETION**: [X/Y completed]
|
||||
- **QUALITY-STANDARD**: [X/Y completed]
|
||||
- **Quality Gates**: [PASS/FAIL]
|
||||
- **Ready for Validation**: [YES/NO]
|
||||
|
||||
|
||||
### IMPROVEMENT Items (Deferred)
|
||||
|
||||
[List items marked as IMPROVEMENT that were not implemented]
|
||||
```
|
||||
|
||||
### Completion Verification
|
||||
|
||||
7. **Final validation before handoff**
|
||||
|
||||
- Verify all REQUIRED-FOR-COMPLETION items addressed
|
||||
- Verify all QUALITY-STANDARD items addressed per project requirements
|
||||
- Confirm project quality gates pass
|
||||
|
|
@ -203,6 +228,7 @@ Evidence: [Test results/screenshots]
|
|||
## Error Handling
|
||||
|
||||
If implementation encounters blockers:
|
||||
|
||||
1. Document the specific blocker and attempted solutions
|
||||
2. Identify if blocker affects REQUIRED-FOR-COMPLETION or QUALITY-STANDARD classification
|
||||
3. Update story with blocker details and impact
|
||||
|
|
@ -210,6 +236,7 @@ If implementation encounters blockers:
|
|||
5. Complete remaining non-blocked fixes
|
||||
|
||||
If quality gates fail:
|
||||
|
||||
1. Identify specific failures and root causes
|
||||
2. Fix issues systematically
|
||||
3. Re-run quality gates after each fix
|
||||
|
|
@ -227,6 +254,6 @@ If quality gates fail:
|
|||
## Integration Points
|
||||
|
||||
- **Input from:** consolidate-review-feedback task (architect agent)
|
||||
- **Output to:** validate-consolidated-fixes task (architect agent)
|
||||
- **Output to:** validate-consolidated-fixes task (architect agent)
|
||||
- **Dependencies:** Story file with consolidation summary
|
||||
- **Quality Gates:** Project-specific validation commands must pass
|
||||
- **Quality Gates:** Project-specific validation commands must pass
|
||||
|
|
|
|||
|
|
@ -10,6 +10,7 @@ Complete comprehensive story implementation including code development, testing,
|
|||
## Context
|
||||
|
||||
This task handles the core development work for a story:
|
||||
|
||||
- Implements all acceptance criteria and requirements
|
||||
- Integrates with project-specific build and testing tools
|
||||
- Executes code generation tools when needed (type sync, API clients, etc.)
|
||||
|
|
@ -19,6 +20,7 @@ This task handles the core development work for a story:
|
|||
## Inputs
|
||||
|
||||
### Required
|
||||
|
||||
- `story_file` (string): Path to the approved story file with implementation guidance
|
||||
- `epic_number` (string): Epic number for context and file organization
|
||||
- `story_number` (string): Story number for tracking and coordination
|
||||
|
|
@ -35,20 +37,23 @@ This task handles the core development work for a story:
|
|||
### Pre-Implementation Analysis
|
||||
|
||||
1. **Review story requirements and technical guidance**
|
||||
|
||||
- Read story file thoroughly including acceptance criteria
|
||||
- Review Dev Technical Guidance section for architecture constraints
|
||||
- Understand file locations and project structure requirements
|
||||
- Identify any previous story insights or lessons learned
|
||||
|
||||
2. **Assess project context and build system**
|
||||
|
||||
|
||||
**Auto-detect project configuration:**
|
||||
|
||||
- Identify project build system from configuration files
|
||||
- Detect available development tools and commands
|
||||
- Review project-specific quality standards
|
||||
- Understand testing and validation approach
|
||||
|
||||
|
||||
**Use project-defined quality gates:**
|
||||
|
||||
- Use project's configured build, test, and quality commands
|
||||
- Follow project's established coding standards
|
||||
- Apply project's validation requirements
|
||||
|
|
@ -56,14 +61,16 @@ This task handles the core development work for a story:
|
|||
### Implementation Process
|
||||
|
||||
3. **Implement acceptance criteria systematically**
|
||||
|
||||
|
||||
**Follow story task sequence:**
|
||||
|
||||
- Work through tasks/subtasks in order specified in story
|
||||
- Complete each acceptance criteria before moving to next
|
||||
- Test functionality as you implement
|
||||
- Document any deviations from planned approach
|
||||
|
||||
**For each acceptance criteria:**
|
||||
|
||||
- Read the specific requirement thoroughly
|
||||
- Implement following project coding standards
|
||||
- Write unit tests as required by project testing strategy
|
||||
|
|
@ -73,57 +80,66 @@ This task handles the core development work for a story:
|
|||
4. **Handle code generation and synchronization (if applicable)**
|
||||
|
||||
**Use project-configured code generation:**
|
||||
|
||||
- Check project documentation for generation commands
|
||||
- Use project's established generation workflow
|
||||
- Identify when generation is needed (after API/schema changes)
|
||||
- Follow project's verification process for generated code
|
||||
|
||||
|
||||
**Common generation scenarios:**
|
||||
|
||||
- Type definitions from API schemas
|
||||
- Client code from API specifications
|
||||
- Client code from API specifications
|
||||
- Protocol buffer implementations
|
||||
- GraphQL type definitions
|
||||
|
||||
|
||||
**Verification:**
|
||||
|
||||
- Ensure generated code integrates properly
|
||||
- Include generated code in project quality validation
|
||||
- Test functionality of generated components
|
||||
|
||||
5. **Validate using project-defined quality gates**
|
||||
|
||||
|
||||
**Use project's quality validation approach:**
|
||||
|
||||
- Run project's configured formatting tools
|
||||
- Execute project's linting and static analysis
|
||||
- Perform project's type checking (if applicable)
|
||||
- Run project's test suite
|
||||
- Execute project's build process
|
||||
|
||||
|
||||
**Quality gate discovery:**
|
||||
|
||||
- Check project scripts/commands in configuration files
|
||||
- Review project CI/CD pipeline configuration
|
||||
- Consult project README or documentation
|
||||
- Use project's established development workflow
|
||||
|
||||
|
||||
**Fallback approaches:**
|
||||
|
||||
- If project commands are unclear, check standard locations
|
||||
- Document any quality gates that cannot be determined
|
||||
- Apply manual validation where automated tools unavailable
|
||||
|
||||
6. **Test implementation comprehensively**
|
||||
|
||||
|
||||
**Unit testing:**
|
||||
|
||||
- Write unit tests for new functionality following project patterns
|
||||
- Ensure test coverage meets project requirements
|
||||
- Test edge cases and error conditions
|
||||
- Mock external dependencies appropriately
|
||||
|
||||
**Integration testing:**
|
||||
|
||||
- Test integration with existing systems
|
||||
- Verify API endpoints work correctly
|
||||
- Test database interactions if applicable
|
||||
- Validate frontend-backend integration
|
||||
|
||||
**Functional testing:**
|
||||
|
||||
- Test all acceptance criteria manually
|
||||
- Verify user journeys work end-to-end
|
||||
- Test accessibility if required by project
|
||||
|
|
@ -132,59 +148,69 @@ This task handles the core development work for a story:
|
|||
### Documentation and Status Management
|
||||
|
||||
7. **Update story file with implementation details**
|
||||
|
||||
|
||||
```markdown
|
||||
## Implementation Details
|
||||
|
||||
|
||||
**Status**: In Progress → Complete
|
||||
**Implementation Date**: [Current date]
|
||||
**Quality Gates**: [PASS/FAIL status]
|
||||
|
||||
|
||||
### Acceptance Criteria Implementation
|
||||
|
||||
|
||||
#### AC1: [Description]
|
||||
|
||||
- **Implementation**: [What was built and how]
|
||||
- **Files Modified**: [List of files changed]
|
||||
- **Tests Added**: [Unit/integration tests created]
|
||||
- **Validation**: [How it was tested]
|
||||
|
||||
|
||||
#### AC2: [Description]
|
||||
|
||||
- **Implementation**: [What was built and how]
|
||||
- **Files Modified**: [List of files changed]
|
||||
- **Tests Added**: [Unit/integration tests created]
|
||||
- **Validation**: [How it was tested]
|
||||
|
||||
|
||||
### Code Generation Executed
|
||||
|
||||
- **Tools Run**: [List of generation commands executed]
|
||||
- **Reason**: [Why generation was needed - backend changes, schema updates, etc.]
|
||||
- **Generated Files**: [Files created/updated by generation]
|
||||
- **Validation**: [How generated code was verified]
|
||||
|
||||
|
||||
### Quality Gates Status
|
||||
|
||||
**Project Configuration:** [Description of detected project setup]
|
||||
|
||||
|
||||
**Executed Quality Gates:**
|
||||
|
||||
- [Gate 1]: [PASS/FAIL/NOT_APPLICABLE] - [Command/method used]
|
||||
- [Gate 2]: [PASS/FAIL/NOT_APPLICABLE] - [Command/method used]
|
||||
- [Gate 3]: [PASS/FAIL/NOT_APPLICABLE] - [Command/method used]
|
||||
|
||||
|
||||
**Project-Specific Validation:**
|
||||
|
||||
- [Custom validation 1]: [PASS/FAIL/NOT_APPLICABLE]
|
||||
- [Custom validation 2]: [PASS/FAIL/NOT_APPLICABLE]
|
||||
|
||||
|
||||
**Quality Assessment:**
|
||||
|
||||
- **Overall Status**: [PASS/NEEDS_ATTENTION]
|
||||
- **Manual Review**: [COMPLETED/NOT_REQUIRED]
|
||||
|
||||
|
||||
### Technical Decisions Made
|
||||
|
||||
- **Decision 1**: [Context and rationale]
|
||||
- **Decision 2**: [Context and rationale]
|
||||
|
||||
|
||||
### Challenges Encountered
|
||||
|
||||
- **Challenge**: [Description and solution]
|
||||
- **Lessons Learned**: [Insights for future stories]
|
||||
|
||||
|
||||
### Implementation Status
|
||||
|
||||
- **All AC Completed**: [YES/NO]
|
||||
- **Quality Gates Passing**: [YES/NO]
|
||||
- **Ready for Review**: [YES/NO]
|
||||
|
|
@ -221,6 +247,7 @@ This task handles the core development work for a story:
|
|||
## Error Handling
|
||||
|
||||
If implementation encounters blockers:
|
||||
|
||||
1. Document the specific blocker and attempted solutions
|
||||
2. Identify if blocker affects acceptance criteria completion
|
||||
3. Update story with blocker details and impact assessment
|
||||
|
|
@ -228,6 +255,7 @@ If implementation encounters blockers:
|
|||
5. Complete remaining non-blocked acceptance criteria
|
||||
|
||||
If quality gates fail:
|
||||
|
||||
1. **Identify project-specific failures and root causes**
|
||||
- Document which project type was detected
|
||||
- Record specific commands that failed
|
||||
|
|
@ -248,6 +276,7 @@ If quality gates fail:
|
|||
6. **Do not proceed to review until all available gates pass**
|
||||
|
||||
If code generation fails:
|
||||
|
||||
1. **Verify backend changes requiring generation are correct**
|
||||
- Check for API schema changes, protobuf definitions, etc.
|
||||
- Confirm generation is actually required for the changes made
|
||||
|
|
@ -281,4 +310,4 @@ If code generation fails:
|
|||
- **Input from:** approve-story-for-development and setup-development-environment tasks
|
||||
- **Output to:** pre_review_validation step
|
||||
- **Dependencies:** Project build system, quality gate commands, story template compliance
|
||||
- **Tools:** Project-specific build system, testing frameworks, code generation tools
|
||||
- **Tools:** Project-specific build system, testing frameworks, code generation tools
|
||||
|
|
|
|||
|
|
@ -1,21 +1,25 @@
|
|||
# Party Mode Learning Review
|
||||
|
||||
## Task Overview
|
||||
|
||||
**Agent:** architect (Technical Architect - Facilitator and Documenter)
|
||||
**Action Type:** collaborative-learning-review
|
||||
**Duration:** Flexible based on learning complexity
|
||||
**Participants:** Configurable at execution time based on story complexity and learning items
|
||||
**Collaborators:** Selected based on learning domain expertise requirements
|
||||
**Collaborators:** Selected based on learning domain expertise requirements
|
||||
|
||||
## Purpose
|
||||
|
||||
Time-boxed collaborative review of learning triage items to validate priorities, assign ownership, and create actionable next steps with team consensus.
|
||||
|
||||
## Inputs
|
||||
|
||||
- Story file with completed ## Learning Triage section
|
||||
- Learning items from capture-learning-triage task
|
||||
- Implementation context and metrics
|
||||
|
||||
## Outputs
|
||||
|
||||
- Validated learning priorities with team consensus
|
||||
- Clear ownership assignments and timelines
|
||||
- Action items for immediate implementation
|
||||
|
|
@ -24,7 +28,9 @@ Time-boxed collaborative review of learning triage items to validate priorities,
|
|||
## Multi-Agent Collaboration Protocol
|
||||
|
||||
### Pre-Review Setup
|
||||
|
||||
**Architect (Facilitator):**
|
||||
|
||||
```
|
||||
SETUP:
|
||||
- Review learning triage items across categories
|
||||
|
|
@ -36,41 +42,50 @@ SETUP:
|
|||
### Review Process
|
||||
|
||||
#### Round 1: Priority Validation
|
||||
|
||||
**Each Participant Reviews Their Domain:**
|
||||
|
||||
**Architect:** ARCH_CHANGE + TOOLING items
|
||||
|
||||
- Validate technical priority and feasibility
|
||||
- Confirm architecture impact assessment
|
||||
- Suggest alternative solutions if needed
|
||||
|
||||
**PO:** FUTURE_EPIC + KNOWLEDGE_GAP items
|
||||
**PO:** FUTURE_EPIC + KNOWLEDGE_GAP items
|
||||
|
||||
- Validate business value and roadmap fit
|
||||
- Confirm epic candidate priorities
|
||||
- Assess resource requirements
|
||||
|
||||
**Dev:** URGENT_FIX + PROCESS_IMPROVEMENT items
|
||||
|
||||
- Validate technical urgency and impact
|
||||
- Confirm implementation effort estimates
|
||||
- Suggest process optimization approaches
|
||||
|
||||
**SM:** PROCESS_IMPROVEMENT + KNOWLEDGE_GAP items
|
||||
|
||||
- Validate team impact and workflow effects
|
||||
- Confirm training and development needs
|
||||
- Assess team capacity for improvements
|
||||
|
||||
**Architect (Session Facilitator):** Technical learning categorization leadership
|
||||
|
||||
- Facilitate technical discussions and pattern identification
|
||||
- Ensure proper categorization of technical learning items
|
||||
- Guide team toward actionable technical decisions
|
||||
- Document final learning categorization with technical context
|
||||
|
||||
#### Round 2: Collaborative Triage
|
||||
|
||||
**Conflict Resolution:**
|
||||
|
||||
- Priority disagreements → Team vote (majority wins)
|
||||
- Ownership disputes → Architect assigns based on technical expertise and SM input
|
||||
- Timeline conflicts → Negotiate based on capacity with architect guidance
|
||||
|
||||
**Consensus Building:**
|
||||
|
||||
```
|
||||
VOTING_PROTOCOL:
|
||||
- Each agent: 3 votes for HIGH priority items
|
||||
|
|
@ -79,12 +94,15 @@ VOTING_PROTOCOL:
|
|||
```
|
||||
|
||||
#### Round 3: Action Planning
|
||||
|
||||
**Immediate Actions (Current Sprint):**
|
||||
|
||||
- URGENT_FIX items → Dev ownership, immediate timeline
|
||||
- High-priority PROCESS items → SM coordination with architect technical input
|
||||
- Critical ARCH_CHANGE → Architect planning
|
||||
|
||||
**Next Sprint Actions:**
|
||||
|
||||
- FUTURE_EPIC candidates → PO backlog integration
|
||||
- Medium-priority improvements → Capacity planning
|
||||
- TOOLING improvements → Infra coordination
|
||||
|
|
@ -92,16 +110,19 @@ VOTING_PROTOCOL:
|
|||
### Rapid Decision Framework
|
||||
|
||||
#### Quick Wins (Implement immediately)
|
||||
|
||||
- Low effort, high impact improvements
|
||||
- Simple process changes
|
||||
- Quick tooling fixes
|
||||
|
||||
#### Strategic Investments (Plan for next sprint)
|
||||
|
||||
- Architecture improvements requiring design
|
||||
- Epic candidates requiring analysis
|
||||
- Process changes requiring team coordination
|
||||
|
||||
#### Long-term Improvements (Backlog)
|
||||
|
||||
- Complex architectural changes
|
||||
- Major tooling upgrades
|
||||
- Comprehensive training programs
|
||||
|
|
@ -109,12 +130,15 @@ VOTING_PROTOCOL:
|
|||
## Collaboration Outputs
|
||||
|
||||
### Validated Learning Items
|
||||
|
||||
Each item updated with team consensus:
|
||||
|
||||
```
|
||||
[CATEGORY]: [Item] - [Consensus Priority: HIGH/MEDIUM/LOW] - [Validated Owner] - [Agreed Timeline] - [Team Vote: X/4]
|
||||
```
|
||||
|
||||
### Action Items
|
||||
|
||||
```
|
||||
IMMEDIATE_ACTIONS (Current Sprint):
|
||||
- [Action] - [Owner] - [Due Date] - [Success Criteria]
|
||||
|
|
@ -127,6 +151,7 @@ BACKLOG_ITEMS:
|
|||
```
|
||||
|
||||
### Team Consensus Summary
|
||||
|
||||
```
|
||||
CONSENSUS_METRICS:
|
||||
- Total items reviewed: [X]
|
||||
|
|
@ -138,6 +163,7 @@ CONSENSUS_METRICS:
|
|||
```
|
||||
|
||||
## Success Criteria
|
||||
|
||||
- [ ] All learning triage items reviewed by relevant domain experts
|
||||
- [ ] Priority conflicts resolved through team consensus
|
||||
- [ ] Clear ownership assigned to each action item
|
||||
|
|
@ -146,43 +172,55 @@ CONSENSUS_METRICS:
|
|||
- [ ] Team consensus achieved on all high-priority items
|
||||
|
||||
## Evidence Documentation
|
||||
|
||||
Update story file with:
|
||||
|
||||
```markdown
|
||||
## Learning Review Results
|
||||
|
||||
**Architect (Facilitator & Technical Documenter):** [Name] | **Date:** [YYYY-MM-DD] | **Duration:** [X minutes]
|
||||
**Participants:** architect (facilitator), po, sm, dev | **Session Type:** Technical Learning Categorization
|
||||
|
||||
### Team Consensus Items
|
||||
|
||||
#### IMMEDIATE_ACTIONS (Current Sprint)
|
||||
|
||||
- [Action] - [Owner] - [Due: YYYY-MM-DD] - [Success Criteria] | Team Vote: [X/4]
|
||||
|
||||
#### NEXT_SPRINT_ACTIONS
|
||||
#### NEXT_SPRINT_ACTIONS
|
||||
|
||||
- [Action] - [Owner] - [Sprint Planning Item] - [Dependencies] | Team Vote: [X/4]
|
||||
|
||||
#### BACKLOG_ITEMS
|
||||
|
||||
- [Action] - [Owner] - [Epic/Initiative] - [Prerequisites] | Team Vote: [X/4]
|
||||
|
||||
### Consensus Metrics
|
||||
|
||||
- **Items Reviewed:** [X] | **High Priority:** [X] | **Immediate Actions:** [X]
|
||||
- **Priority Conflicts Resolved:** [X] | **Team Consensus:** [X%]
|
||||
- **Next Sprint Integration:** [X items] | **Backlog Items:** [X items]
|
||||
|
||||
### Key Decisions
|
||||
|
||||
- [Decision] - [Rationale] - [Team Vote: X/4]
|
||||
- [Decision] - [Rationale] - [Team Vote: X/4]
|
||||
```
|
||||
|
||||
## Integration Points
|
||||
|
||||
- **Input from:** capture-learning-triage (learning items)
|
||||
- **Output to:** commit-and-prepare-pr (final story state)
|
||||
- **Handoff:** "Technical learning review complete. Architect-led categorization consensus achieved. Technical documentation updated. Ready for commit and PR preparation."
|
||||
|
||||
## Session Management
|
||||
|
||||
- **Scope-driven duration:** Based on learning complexity rather than fixed time
|
||||
- **Focus on outcomes:** Prioritize consensus over rigid timing
|
||||
- **Flexible participation:** Include relevant domain experts as needed
|
||||
|
||||
## Facilitation Tips for Architect
|
||||
|
||||
- Lead technical learning categorization and pattern identification
|
||||
- Keep discussions focused on actionable technical outcomes
|
||||
- Use time-boxing to prevent lengthy technical debates
|
||||
|
|
@ -192,8 +230,9 @@ Update story file with:
|
|||
- Maintain final ownership of technical learning documentation
|
||||
|
||||
## LLM Optimization Notes
|
||||
|
||||
- Time-boxed collaboration prevents extended discussions
|
||||
- Clear voting protocol resolves conflicts efficiently
|
||||
- Structured output format enables rapid scanning
|
||||
- Evidence-based consensus building reduces subjective debates
|
||||
- Action-oriented focus drives immediate value delivery
|
||||
- Action-oriented focus drives immediate value delivery
|
||||
|
|
|
|||
|
|
@ -1,44 +1,52 @@
|
|||
# Setup Development Environment for Story
|
||||
|
||||
## Purpose
|
||||
|
||||
Ensure development environment is ready and validated for story implementation. Focused on story-specific setup and validation.
|
||||
|
||||
## Inputs
|
||||
|
||||
- `story_file`: Path to the approved story file
|
||||
|
||||
## Task Execution
|
||||
|
||||
### 1. Environment Health Check
|
||||
|
||||
- Verify project-specific development services are running (check project documentation for required services)
|
||||
- Check service connectivity and responsiveness based on project architecture
|
||||
- Validate port availability and configuration as defined in project setup
|
||||
- Ensure no service conflicts or failures in the development stack
|
||||
|
||||
### 2. Development Dependencies
|
||||
|
||||
- Verify all required dependencies are installed
|
||||
- Check package versions match project requirements
|
||||
- Check package versions match project requirements
|
||||
- Validate development tools are available
|
||||
- Ensure environment variables are properly configured
|
||||
|
||||
### 3. Build and Quality Validation
|
||||
|
||||
- Execute complete build process to ensure success
|
||||
- Run linting and type checking to establish baseline
|
||||
- Verify all existing tests pass before new development
|
||||
- Check that development server starts successfully
|
||||
|
||||
### 4. Authentication and Security
|
||||
|
||||
- Test authentication flow with development credentials (if project requires authentication)
|
||||
- Verify authorization rules are working according to project security model
|
||||
- Check security configurations are properly set per project requirements
|
||||
- Validate API access and permissions as defined in project documentation
|
||||
|
||||
### 5. Story-Specific Validation
|
||||
|
||||
- Review story requirements for any special environment needs
|
||||
- Check if story requires specific tools or configurations
|
||||
- Validate access to necessary external services (if applicable)
|
||||
- Ensure development environment supports story implementation
|
||||
|
||||
## Success Criteria
|
||||
|
||||
- All services responding correctly
|
||||
- Build process completes without errors
|
||||
- Baseline quality checks pass (lint, typecheck, tests)
|
||||
|
|
@ -46,17 +54,20 @@ Ensure development environment is ready and validated for story implementation.
|
|||
- Development environment ready for story work
|
||||
|
||||
## Outputs
|
||||
|
||||
- `environment_status`: "READY" or "ISSUES_FOUND"
|
||||
- `issues_found`: List of any problems requiring resolution
|
||||
- `setup_notes`: Any special configurations or notes for development
|
||||
|
||||
## Failure Actions
|
||||
|
||||
- Document specific environment issues
|
||||
- Attempt automatic resolution of common problems
|
||||
- Provide clear remediation steps
|
||||
- Halt development until environment is stable
|
||||
|
||||
## Notes
|
||||
|
||||
- Lightweight validation focused on story development readiness
|
||||
- Not comprehensive infrastructure validation (use validate-infrastructure for that)
|
||||
- Designed to quickly verify environment is ready for immediate story work
|
||||
- Designed to quickly verify environment is ready for immediate story work
|
||||
|
|
|
|||
|
|
@ -1,21 +1,25 @@
|
|||
# Update Epic Progress
|
||||
|
||||
## Task Overview
|
||||
|
||||
**Agent:** sm (Scrum Master - Progress Tracking Owner)
|
||||
**Action Type:** epic-progress-update
|
||||
**Duration:** 3-5 minutes
|
||||
**LLM-Optimized:** Structured epic tracking with learning integration
|
||||
**LLM-Optimized:** Structured epic tracking with learning integration
|
||||
|
||||
## Purpose
|
||||
|
||||
Track story completion within epic context, update epic progress indicators, and schedule learning extraction for continuous improvement.
|
||||
|
||||
## Inputs
|
||||
|
||||
- Completed story file with PR information
|
||||
- Epic file (docs/prd/epic{epic_number}.md)
|
||||
- Learning items and action assignments
|
||||
- PR creation confirmation
|
||||
|
||||
## Outputs
|
||||
|
||||
- Updated epic file with story completion status
|
||||
- Learning extraction scheduled in epic context
|
||||
- Epic progress metrics updated
|
||||
|
|
@ -24,18 +28,21 @@ Track story completion within epic context, update epic progress indicators, and
|
|||
## Execution Steps
|
||||
|
||||
### Step 1: Calculate Epic Completion Status (1 minute)
|
||||
|
||||
Calculate current epic completion status:
|
||||
|
||||
```markdown
|
||||
## Epic Completion Detection
|
||||
|
||||
### Story Completion Analysis
|
||||
|
||||
- **Total Stories in Epic:** {total_story_count}
|
||||
- **Completed Stories:** {completed_story_count}
|
||||
- **Completion Percentage:** {completion_percentage}%
|
||||
- **Epic Status:** {IN_PROGRESS/COMPLETE}
|
||||
|
||||
### Completion Criteria Check
|
||||
|
||||
- [ ] All stories marked as "Done - Delivered"
|
||||
- [ ] All PRs merged successfully
|
||||
- [ ] No remaining story dependencies
|
||||
|
|
@ -46,24 +53,28 @@ Calculate current epic completion status:
|
|||
```
|
||||
|
||||
### Step 2: Update Epic Progress Tracking (2 minutes)
|
||||
|
||||
Update epic file with story completion:
|
||||
|
||||
```markdown
|
||||
## Epic {epic_number} Progress Tracking
|
||||
|
||||
### Story Completion Status
|
||||
|
||||
- ✅ **Story {story_number}:** {story_title} | Status: DONE | PR: #{pr_number} | Completed: {YYYY-MM-DD}
|
||||
- ✅ **Story {previous}:** {previous_title} | Status: DONE | PR: #{prev_pr} | Completed: {prev_date}
|
||||
- 🚧 **Story {next}:** {next_title} | Status: READY | Target: {target_date}
|
||||
- 📋 **Story {future}:** {future_title} | Status: DRAFT | Dependencies: {deps}
|
||||
|
||||
### Epic Metrics
|
||||
|
||||
- **Stories Completed:** {completed_count}/{total_stories} ({completion_percentage}%)
|
||||
- **Epic Velocity:** {stories_per_sprint} stories/sprint
|
||||
- **Quality Score:** {avg_quality_score}/10 (average across completed stories)
|
||||
- **Learning Items:** {total_learning_items} captured across {completed_count} stories
|
||||
|
||||
### Epic Timeline
|
||||
|
||||
- **Epic Start:** {epic_start_date}
|
||||
- **Current Sprint:** Sprint {current_sprint}
|
||||
- **Stories This Sprint:** {current_sprint_stories}
|
||||
|
|
@ -72,17 +83,21 @@ Update epic file with story completion:
|
|||
```
|
||||
|
||||
### Step 3: Epic Retrospective Preparation (1 minute - if applicable)
|
||||
|
||||
Prepare epic retrospective data if epic is complete:
|
||||
|
||||
```markdown
|
||||
## Epic Retrospective Preparation (Only if Epic Complete)
|
||||
|
||||
### All Story Data Collection
|
||||
|
||||
- **Story Files:** {story_file_list}
|
||||
- **Learning Items:** {total_learning_items} across {story_count} stories
|
||||
- **Quality Metrics:** Average {avg_quality_score}/10
|
||||
- **Timeline Data:** {start_date} to {completion_date} ({total_days} days)
|
||||
|
||||
### Epic Metrics Summary
|
||||
|
||||
- **Total Effort:** {total_story_points} story points
|
||||
- **Average Velocity:** {avg_velocity} points/sprint
|
||||
- **Review Rounds:** Average {avg_review_rounds} per story
|
||||
|
|
@ -94,64 +109,78 @@ Prepare epic retrospective data if epic is complete:
|
|||
```
|
||||
|
||||
### Step 4: Schedule Learning Extraction (1 minute)
|
||||
|
||||
Add learning extraction scheduling to epic:
|
||||
|
||||
```markdown
|
||||
## Learning Extraction Schedule
|
||||
|
||||
### Story {story_number} Learning Items
|
||||
|
||||
**Extraction Date:** {YYYY-MM-DD} | **Review Status:** COMPLETE | **Action Items:** {action_count}
|
||||
|
||||
#### Immediate Actions (Current Sprint)
|
||||
|
||||
- {action_1} - @{owner} - Due: {date} - Status: {PENDING/IN_PROGRESS/DONE}
|
||||
- {action_2} - @{owner} - Due: {date} - Status: {PENDING/IN_PROGRESS/DONE}
|
||||
|
||||
#### Next Sprint Integration
|
||||
|
||||
- {next_action_1} - @{owner} - Sprint Planning Item
|
||||
- {next_action_2} - @{owner} - Sprint Planning Item
|
||||
|
||||
#### Future Epic Candidates (Generated)
|
||||
|
||||
- **{epic_candidate_1}** - Priority: {HIGH/MEDIUM/LOW} - Target: Epic {target_epic}
|
||||
- **{epic_candidate_2}** - Priority: {HIGH/MEDIUM/LOW} - Target: Epic {target_epic}
|
||||
|
||||
### Cumulative Learning Insights
|
||||
|
||||
**Pattern Analysis:** {patterns_identified} patterns identified across {completed_count} stories
|
||||
|
||||
- **Most Common:** {common_pattern} - Occurred in {pattern_count} stories
|
||||
- **Critical Issues:** {critical_pattern} - Requires epic-level attention
|
||||
- **Process Improvements:** {process_improvements} - Affecting team velocity
|
||||
```
|
||||
|
||||
### Step 5: Update Epic Health Indicators (1 minute)
|
||||
|
||||
```markdown
|
||||
## Epic Health Dashboard
|
||||
|
||||
### Current Status: {GREEN/YELLOW/RED}
|
||||
|
||||
- **Scope:** {ON_TRACK/AT_RISK/BLOCKED} - {scope_status_detail}
|
||||
- **Timeline:** {ON_TRACK/AT_RISK/DELAYED} - {timeline_status_detail}
|
||||
- **Timeline:** {ON_TRACK/AT_RISK/DELAYED} - {timeline_status_detail}
|
||||
- **Quality:** {HIGH/MEDIUM/LOW} - Avg: {quality_score}/10
|
||||
- **Team Velocity:** {STABLE/INCREASING/DECREASING} - {velocity_trend}
|
||||
|
||||
### Risk Indicators
|
||||
|
||||
- **Scope Creep:** {risk_level} - {scope_changes} changes since start
|
||||
- **Quality Debt:** {risk_level} - {debt_items} items requiring attention
|
||||
- **Team Capacity:** {risk_level} - {capacity_utilization}% utilization
|
||||
- **Learning Integration:** {risk_level} - {unaddressed_items} unaddressed items
|
||||
|
||||
### Success Metrics
|
||||
|
||||
- **Business Value Delivered:** {value_score}/10
|
||||
- **Technical Quality:** {tech_score}/10
|
||||
- **Technical Quality:** {tech_score}/10
|
||||
- **Team Learning:** {learning_score}/10
|
||||
- **Process Efficiency:** {efficiency_score}/10
|
||||
```
|
||||
|
||||
### Step 6: Assess Next Story Readiness (1 minute - if epic not complete)
|
||||
|
||||
```markdown
|
||||
## Next Story Readiness Assessment
|
||||
|
||||
### Story {next_story_number}: {next_story_title}
|
||||
|
||||
**Readiness Status:** {READY/NEEDS_REFINEMENT/BLOCKED}
|
||||
|
||||
#### Readiness Checklist
|
||||
|
||||
- [ ] **Epic Context:** Clear and validated
|
||||
- [ ] **Business Value:** Defined and approved
|
||||
- [ ] **Technical Dependencies:** {resolved_count}/{total_deps} resolved
|
||||
|
|
@ -159,26 +188,31 @@ Add learning extraction scheduling to epic:
|
|||
- [ ] **Learning Integration:** Previous story insights applied
|
||||
|
||||
#### Blockers and Dependencies
|
||||
|
||||
- {blocker_1} - Owner: @{owner} - Target Resolution: {date}
|
||||
- {dependency_1} - Status: {status} - Required for: {requirement}
|
||||
|
||||
#### Recommendation
|
||||
|
||||
**Action:** {START_IMMEDIATELY/REFINE_FIRST/WAIT_FOR_DEPENDENCIES/EPIC_COMPLETE}
|
||||
**Rationale:** {recommendation_rationale}
|
||||
**Target Start:** {target_start_date}
|
||||
|
||||
#### Epic Completion Auto-Detection
|
||||
|
||||
**Epic Status:** {completion_percentage}% complete
|
||||
**Next Action:** {CONTINUE_STORIES/MANDATORY_EPIC_RETROSPECTIVE}
|
||||
**Epic Retrospective:** {AUTOMATIC_MANDATORY_IF_100%/NOT_REQUIRED}
|
||||
|
||||
⚠️ **AUTOMATIC TRIGGER CONDITIONS:**
|
||||
|
||||
- IF completion_percentage == 100% THEN next_action = MANDATORY_EPIC_RETROSPECTIVE
|
||||
- Epic retrospective is automatically triggered and MANDATORY
|
||||
- Workflow cannot complete without epic retrospective when epic is 100% complete
|
||||
```
|
||||
|
||||
## Success Criteria
|
||||
|
||||
- [ ] Epic completion status calculated and documented
|
||||
- [ ] Epic progress tracking updated with story completion
|
||||
- [ ] Epic retrospective AUTOMATICALLY triggered and prepared (MANDATORY if epic 100% complete)
|
||||
|
|
@ -190,13 +224,16 @@ Add learning extraction scheduling to epic:
|
|||
- [ ] Epic retrospective MANDATORY trigger status automatically determined (100% = REQUIRED)
|
||||
|
||||
## Epic File Updates
|
||||
|
||||
Update `docs/prd/epic{epic_number}.md` with:
|
||||
|
||||
```markdown
|
||||
## Story Implementation Progress
|
||||
|
||||
**Last Updated:** {YYYY-MM-DD} | **Updated By:** SM
|
||||
|
||||
### Current Status
|
||||
|
||||
- **Epic Progress:** {completion_percentage}% complete ({completed}/{total} stories)
|
||||
- **Epic Status:** {IN_PROGRESS/COMPLETE}
|
||||
- **Current Story:** Story {story_number} - DONE (PR #{pr_number})
|
||||
|
|
@ -206,12 +243,14 @@ Update `docs/prd/epic{epic_number}.md` with:
|
|||
- **Retrospective Status:** {REQUIRED_AND_SCHEDULED/NOT_APPLICABLE}
|
||||
|
||||
### Learning Integration Status
|
||||
|
||||
- **Total Learning Items:** {total_items} across {completed_stories} stories
|
||||
- **Immediate Actions:** {immediate_count} (Current Sprint)
|
||||
- **Epic Candidates Generated:** {epic_candidates_count}
|
||||
- **Process Improvements:** {process_count} implemented
|
||||
|
||||
### Next Actions
|
||||
|
||||
- [ ] {next_action_1} - Due: {date}
|
||||
- [ ] {next_action_2} - Due: {date}
|
||||
- [ ] Start Story {next_number} - Target: {target_date}
|
||||
|
|
@ -219,11 +258,13 @@ Update `docs/prd/epic{epic_number}.md` with:
|
|||
```
|
||||
|
||||
## Integration Points
|
||||
|
||||
- **Input from:** create-comprehensive-pr (PR creation complete)
|
||||
- **Output to:** epic-party-mode-retrospective (MANDATORY AUTO-TRIGGER if epic 100% complete) OR Next story workflow initiation (if epic incomplete)
|
||||
- **Handoff:** "Epic progress updated. Story {story_number} complete. Epic completion: {completion_percentage}%. MANDATORY epic retrospective: {AUTO_TRIGGERED/NOT_REQUIRED}. When epic = 100%, retrospective is automatically triggered and MANDATORY."
|
||||
|
||||
## Epic Progress Visualization
|
||||
|
||||
```
|
||||
EPIC_PROGRESS_BAR:
|
||||
Epic {epic_number}: [████████░░] {completion_percentage}% | {completed}/{total} stories
|
||||
|
|
@ -232,15 +273,17 @@ Health: {health_color} | Learning: {learning_items} items | ETA: {completion_dat
|
|||
```
|
||||
|
||||
## Learning Integration Benefits
|
||||
|
||||
- **Continuous Improvement:** Each story informs the next
|
||||
- **Epic-Level Insights:** Patterns emerge across multiple stories
|
||||
- **Epic-Level Insights:** Patterns emerge across multiple stories
|
||||
- **Future Planning:** Epic candidates feed roadmap planning
|
||||
- **Process Optimization:** Velocity and quality trends guide improvements
|
||||
- **Risk Mitigation:** Early identification of epic-level issues
|
||||
|
||||
## LLM Optimization Notes
|
||||
|
||||
- Structured progress tracking enables rapid epic health assessment
|
||||
- Learning integration prevents knowledge loss at epic level
|
||||
- Metrics-driven updates provide objective progress measurement
|
||||
- Health indicators enable proactive epic management
|
||||
- Token-efficient format maintains comprehensive tracking without overwhelming detail
|
||||
- Token-efficient format maintains comprehensive tracking without overwhelming detail
|
||||
|
|
|
|||
|
|
@ -1,24 +1,26 @@
|
|||
# validate-consolidated-fixes
|
||||
|
||||
**Agent:** architect
|
||||
**Agent:** sm
|
||||
**Type:** BatchTask
|
||||
|
||||
## Purpose
|
||||
|
||||
Validate that consolidated fixes have been properly implemented by examining story documentation and using Playwright MCP for UX changes, serving as the single validation gate for Round 2+ iterations.
|
||||
Validate that consolidated fixes have been properly implemented according to the consolidated feedback priorities and classification, serving as process compliance validation for implementation completeness.
|
||||
|
||||
## Context
|
||||
|
||||
This task provides efficient architect-only validation after comprehensive Round 1 reviews:
|
||||
- Validates fixes against original consolidated feedback
|
||||
- Uses story documentation as primary evidence source
|
||||
- Employs Playwright MCP for UX validation when needed
|
||||
- Provides final approval or requests additional fixes
|
||||
This task provides efficient SM process validation after comprehensive Round 1 reviews and dev implementation:
|
||||
|
||||
- Validates fixes against original consolidated feedback priorities (REQUIRED-FOR-COMPLETION/QUALITY-STANDARD)
|
||||
- Uses story documentation and implementation details as evidence source
|
||||
- Focuses on process compliance rather than deep technical validation
|
||||
- Provides final approval or requests additional fixes based on completion criteria
|
||||
- Eliminates need for full re-review cycles
|
||||
|
||||
## Inputs
|
||||
|
||||
### Required
|
||||
|
||||
- `story_file` (string): Path to story file with implementation details
|
||||
- `original_feedback` (object): Original consolidated feedback for comparison
|
||||
- `implemented_fixes` (object): Summary of changes implemented by dev
|
||||
|
|
@ -35,6 +37,7 @@ This task provides efficient architect-only validation after comprehensive Round
|
|||
### Pre-Validation Analysis
|
||||
|
||||
1. **Review implementation documentation**
|
||||
|
||||
- Read story file implementation section thoroughly
|
||||
- Compare implemented fixes against original consolidated feedback
|
||||
- Identify any REQUIRED-FOR-COMPLETION items that were not addressed
|
||||
|
|
@ -49,91 +52,104 @@ This task provides efficient architect-only validation after comprehensive Round
|
|||
### Validation Process
|
||||
|
||||
3. **Validate technical fixes**
|
||||
|
||||
|
||||
**Architecture fixes validation:**
|
||||
|
||||
- Review code changes described in story documentation
|
||||
- Verify security improvements implemented correctly
|
||||
- Check performance optimizations are reasonable
|
||||
- Confirm technical debt addressed appropriately
|
||||
|
||||
|
||||
**Quality fixes validation:**
|
||||
|
||||
- Verify test coverage improvements documented
|
||||
- Check that quality gates are passing
|
||||
- Confirm code quality standards maintained
|
||||
- Validate error handling additions
|
||||
|
||||
4. **Validate business fixes**
|
||||
|
||||
|
||||
**Acceptance criteria validation:**
|
||||
|
||||
- Confirm AC adjustments align with business requirements
|
||||
- Verify business rule corrections documented properly
|
||||
- Check user journey improvements are logical
|
||||
- Validate data validation enhancements
|
||||
|
||||
|
||||
**Epic alignment validation:**
|
||||
|
||||
- Ensure changes maintain epic scope and objectives
|
||||
- Verify business value delivery still intact
|
||||
- Check that project phase boundaries respected
|
||||
|
||||
5. **Validate UX fixes using project-appropriate testing tools**
|
||||
|
||||
|
||||
**When UX validation needed:**
|
||||
|
||||
- User interface changes described in story (web, desktop, mobile, CLI, etc.)
|
||||
- User interaction flow modifications
|
||||
- Accessibility improvements requiring testing
|
||||
- Design consistency updates
|
||||
|
||||
|
||||
**Comprehensive UI Testing Protocol:**
|
||||
|
||||
|
||||
**Phase 1: Environment Setup**
|
||||
|
||||
- Launch UI testing tools as specified in project documentation (check README.md or test configuration)
|
||||
- Use clean testing environment appropriate for project type (browser, desktop app, mobile simulator, CLI, etc.)
|
||||
- Clear relevant caches and state according to project architecture
|
||||
- Set appropriate viewport/window size for project target platform
|
||||
- Configure testing environment for debugging (enable logging as per project standards)
|
||||
|
||||
|
||||
**Phase 2: Pre-Testing Validation**
|
||||
|
||||
- Navigate to application entry point (URL, app launch, CLI command, etc.)
|
||||
- Verify application loads/starts without errors (check relevant logs)
|
||||
- Take baseline screenshot/capture of unaffected areas for comparison
|
||||
- Document initial application state and version
|
||||
|
||||
|
||||
**Phase 3: Feature-Specific Testing**
|
||||
|
||||
- Navigate systematically to each UI area mentioned in story fixes
|
||||
- For each changed component/page:
|
||||
* Capture screenshot BEFORE interacting
|
||||
* Test all documented user interactions (clicks, form submissions, navigation)
|
||||
* Verify visual changes match story implementation descriptions
|
||||
* Test error states and edge cases if applicable
|
||||
* Capture screenshot AFTER each significant interaction
|
||||
* Validate loading states and transitions work correctly
|
||||
|
||||
- Capture screenshot BEFORE interacting
|
||||
- Test all documented user interactions (clicks, form submissions, navigation)
|
||||
- Verify visual changes match story implementation descriptions
|
||||
- Test error states and edge cases if applicable
|
||||
- Capture screenshot AFTER each significant interaction
|
||||
- Validate loading states and transitions work correctly
|
||||
|
||||
**Phase 4: Accessibility & Responsive Testing (if applicable to project type)**
|
||||
|
||||
- Test keyboard/alternative navigation for new/changed interactive elements
|
||||
- Verify accessibility features if improvements documented (ARIA, screen reader compatibility, etc.)
|
||||
- Test responsive behavior according to project target platforms (mobile, tablet, desktop, multiple screen sizes)
|
||||
- Validate contrast and readability for visual changes according to project standards
|
||||
|
||||
|
||||
**Phase 5: Cross-Platform Compatibility (if critical changes)**
|
||||
|
||||
- Repeat core tests across project target platforms (different browsers, OS versions, device types, etc.)
|
||||
- Document any platform-specific issues discovered
|
||||
- Capture comparative evidence across platforms for visual/behavioral changes
|
||||
|
||||
|
||||
**Phase 6: Evidence Documentation and Cleanup**
|
||||
|
||||
- Save all screenshots/captures to temporary validation directory with descriptive filenames (feature_state_timestamp.png)
|
||||
- Record any errors or warnings encountered in relevant logs
|
||||
- Document specific testing commands/tools used for reproducibility
|
||||
- Create testing summary with pass/fail status for each tested component
|
||||
- Note: All testing artifacts are temporary and will be cleaned up after validation completion
|
||||
|
||||
|
||||
**Testing Session Management:**
|
||||
|
||||
- Maintain consistent testing context throughout validation for consistency
|
||||
- Reset application state between major test sections to ensure clean state
|
||||
- Restart testing environment if session becomes unstable
|
||||
- Document testing tool versions and configuration used (refer to project documentation)
|
||||
- Clean up testing sessions and temporary files after validation
|
||||
|
||||
|
||||
**File Management:**
|
||||
|
||||
- All screenshots and evidence saved to temporary validation workspace
|
||||
- Artifacts automatically cleaned up after validation completion
|
||||
- Only validation results and decisions persisted in story documentation
|
||||
|
|
@ -142,102 +158,119 @@ This task provides efficient architect-only validation after comprehensive Round
|
|||
### Validation Decision Making
|
||||
|
||||
6. **Assess overall fix quality**
|
||||
|
||||
|
||||
**APPROVED criteria:**
|
||||
|
||||
- All REQUIRED-FOR-COMPLETION items addressed satisfactorily
|
||||
- All QUALITY-STANDARD items addressed per project requirements
|
||||
- Quality gates passing
|
||||
- UX changes validated via browser MCP testing (if applicable)
|
||||
- No new issues introduced
|
||||
- Documentation clear and complete
|
||||
|
||||
|
||||
**NEEDS_FIXES criteria:**
|
||||
|
||||
- Some REQUIRED-FOR-COMPLETION or QUALITY-STANDARD items incomplete or incorrect
|
||||
- Quality gates failing
|
||||
- UX changes not working as expected
|
||||
- Minor issues that can be corrected quickly
|
||||
|
||||
|
||||
**BLOCKED criteria:**
|
||||
|
||||
- Major technical blockers preventing completion
|
||||
- Fundamental misunderstanding of requirements
|
||||
- Scope changes required beyond current story
|
||||
- Environment or infrastructure issues
|
||||
|
||||
7. **Document validation results**
|
||||
|
||||
|
||||
**Update story file with validation findings:**
|
||||
|
||||
```markdown
|
||||
## Round 2+ Validation Results
|
||||
|
||||
|
||||
**Validation Date**: [Current date]
|
||||
**Validation Status**: [APPROVED/NEEDS_FIXES/BLOCKED]
|
||||
|
||||
|
||||
### Architecture Fixes Validation
|
||||
|
||||
- [Fix 1]: ✅ VALIDATED / ❌ NEEDS_WORK / ⚠️ CONCERNS
|
||||
- [Fix 2]: ✅ VALIDATED / ❌ NEEDS_WORK / ⚠️ CONCERNS
|
||||
|
||||
### Business Fixes Validation
|
||||
|
||||
### Business Fixes Validation
|
||||
|
||||
- [Fix 1]: ✅ VALIDATED / ❌ NEEDS_WORK / ⚠️ CONCERNS
|
||||
- [Fix 2]: ✅ VALIDATED / ❌ NEEDS_WORK / ⚠️ CONCERNS
|
||||
|
||||
|
||||
### Quality Fixes Validation
|
||||
|
||||
- [Fix 1]: ✅ VALIDATED / ❌ NEEDS_WORK / ⚠️ CONCERNS
|
||||
- [Fix 2]: ✅ VALIDATED / ❌ NEEDS_WORK / ⚠️ CONCERNS
|
||||
|
||||
|
||||
### UX Fixes Validation (Browser MCP Testing)
|
||||
|
||||
**Browser MCP Tool Used:** [Playwright MCP / Puppeteer MCP / Other Browser MCP]
|
||||
**Testing Session ID:** [Unique identifier for reproducibility]
|
||||
**Test Environment:** [URL, version, browser details]
|
||||
|
||||
|
||||
**Component-Level Results:**
|
||||
|
||||
- [Component 1]: ✅ VALIDATED / ❌ NEEDS_WORK / ⚠️ CONCERNS
|
||||
* **Interaction Testing:** [Pass/Fail with specific interactions tested]
|
||||
* **Visual Validation:** [Pass/Fail with screenshot evidence]
|
||||
* **Accessibility Check:** [Pass/Fail/N/A with specific findings]
|
||||
* **Responsive Testing:** [Pass/Fail across viewports]
|
||||
|
||||
|
||||
- **Interaction Testing:** [Pass/Fail with specific interactions tested]
|
||||
- **Visual Validation:** [Pass/Fail with screenshot evidence]
|
||||
- **Accessibility Check:** [Pass/Fail/N/A with specific findings]
|
||||
- **Responsive Testing:** [Pass/Fail across viewports]
|
||||
|
||||
- [Component 2]: ✅ VALIDATED / ❌ NEEDS_WORK / ⚠️ CONCERNS
|
||||
* **Interaction Testing:** [Pass/Fail with specific interactions tested]
|
||||
* **Visual Validation:** [Pass/Fail with screenshot evidence]
|
||||
* **Accessibility Check:** [Pass/Fail/N/A with specific findings]
|
||||
* **Responsive Testing:** [Pass/Fail across viewports]
|
||||
|
||||
- **Interaction Testing:** [Pass/Fail with specific interactions tested]
|
||||
- **Visual Validation:** [Pass/Fail with screenshot evidence]
|
||||
- **Accessibility Check:** [Pass/Fail/N/A with specific findings]
|
||||
- **Responsive Testing:** [Pass/Fail across viewports]
|
||||
|
||||
**Cross-Browser Compatibility:** [Tested/Not Required]
|
||||
|
||||
- Chrome: [Pass/Fail/Not Tested] - [Specific findings]
|
||||
- Firefox: [Pass/Fail/Not Tested] - [Specific findings]
|
||||
- Firefox: [Pass/Fail/Not Tested] - [Specific findings]
|
||||
- Safari: [Pass/Fail/Not Tested] - [Specific findings]
|
||||
|
||||
|
||||
**Evidence Artifacts:**
|
||||
|
||||
- Screenshots captured: [Count] files saved with naming convention
|
||||
- Console errors logged: [Count] with severity levels
|
||||
- MCP session logs: [Available/Not Available] for debugging
|
||||
|
||||
|
||||
**Overall UX Validation Status:** [PASSED/FAILED/PARTIALLY_PASSED]
|
||||
**Detailed Findings:** [Comprehensive summary of all UX testing results]
|
||||
|
||||
|
||||
### Additional Feedback (if NEEDS_FIXES)
|
||||
|
||||
[Specific, actionable guidance for remaining issues]
|
||||
|
||||
|
||||
### Next Steps
|
||||
|
||||
[Clear direction for completion or additional work needed]
|
||||
```
|
||||
|
||||
### Completion Actions
|
||||
|
||||
8. **Provide clear next steps**
|
||||
|
||||
|
||||
**If APPROVED:**
|
||||
|
||||
- Mark story as ready for delivery
|
||||
- Document successful completion
|
||||
- Note any IMPROVEMENT items for future tracking
|
||||
|
||||
|
||||
**If NEEDS_FIXES:**
|
||||
|
||||
- Provide specific, actionable feedback
|
||||
- Prioritize remaining issues
|
||||
- Set up for another validation cycle
|
||||
- Maintain positive momentum
|
||||
|
||||
|
||||
**If BLOCKED:**
|
||||
|
||||
- Document blockers clearly
|
||||
- Recommend escalation path
|
||||
- Suggest scope adjustments if needed
|
||||
|
|
@ -267,30 +300,29 @@ This task provides efficient architect-only validation after comprehensive Round
|
|||
## Error Handling
|
||||
|
||||
If documentation is insufficient:
|
||||
|
||||
1. Request specific clarification from dev
|
||||
2. Document what additional information is needed
|
||||
3. Provide guidance on documentation standards
|
||||
4. Validate what can be assessed from available information
|
||||
|
||||
If browser MCP testing fails:
|
||||
|
||||
1. **Document failure details comprehensively:**
|
||||
- Specific MCP tool and version used (Playwright MCP, Browser MCP, etc.)
|
||||
- Exact failure scenarios with timestamps
|
||||
- Browser console errors and MCP session logs
|
||||
- Screenshots of failure states if captured
|
||||
|
||||
2. **Attempt alternative browser MCP approaches:**
|
||||
- Try different browser MCP tool if available (switch from Playwright to Browser MCP)
|
||||
- Test in different browser engines (Chromium, Firefox, WebKit)
|
||||
- Use different viewport sizes to isolate responsive issues
|
||||
- Clear browser context completely and retry
|
||||
|
||||
3. **Fallback validation methods:**
|
||||
- Request manual testing documentation from dev with comprehensive screenshots
|
||||
- Require video screen recordings of user interactions for complex flows
|
||||
- Request specific console log outputs for JavaScript errors
|
||||
- Ask for accessibility audit results using browser dev tools
|
||||
|
||||
4. **Escalation procedures:**
|
||||
- Escalate to DevOps if browser MCP infrastructure issues suspected
|
||||
- Involve UX Expert for complex accessibility or interaction validation
|
||||
|
|
@ -298,6 +330,7 @@ If browser MCP testing fails:
|
|||
- Consider scope adjustment if UX changes cannot be properly validated via available MCP tools
|
||||
|
||||
If validation reveals new issues:
|
||||
|
||||
1. Classify as REQUIRED-FOR-COMPLETION vs IMPROVEMENT
|
||||
2. Provide clear guidance for resolution
|
||||
3. Update feedback for next implementation cycle
|
||||
|
|
@ -317,4 +350,4 @@ If validation reveals new issues:
|
|||
- **Output to:** Story completion OR additional fix cycles
|
||||
- **Dependencies:** Story file with implementation documentation
|
||||
- **Tools:** Browser MCP tools (Playwright MCP/Puppeteer MCP/similar) for UX validation, project quality gates
|
||||
- **Escalation:** Product Owner for business decisions, DevOps for infrastructure issues
|
||||
- **Escalation:** Product Owner for business decisions, DevOps for infrastructure issues
|
||||
|
|
|
|||
|
|
@ -11,6 +11,29 @@ workflow:
|
|||
Phase 6: PR Creation and Epic Progress (Delivery + Tracking)
|
||||
Phase 7: Epic Retrospective (MANDATORY when epic reaches 100% completion)
|
||||
type: story-implementation
|
||||
|
||||
shard_configuration:
|
||||
base_path: "docs/stories/"
|
||||
naming_pattern: "epic{epic_number}.story{story_number}.{shard_type}.md"
|
||||
main_story_pattern: "epic{epic_number}.story{story_number}.story.md"
|
||||
max_lines_per_shard: 400
|
||||
shard_types:
|
||||
architecture_review: "arch-review"
|
||||
business_review: "biz-review"
|
||||
process_review: "proc-review"
|
||||
qa_review: "qa-review"
|
||||
ux_review: "ux-review"
|
||||
consolidation: "consolidated"
|
||||
implementation: "implementation"
|
||||
validation: "validation"
|
||||
learning_triage: "learning"
|
||||
learning_review: "review"
|
||||
pr_context: "pr-context"
|
||||
pr_information: "pr-info"
|
||||
auto_shard_triggers:
|
||||
- content_exceeds_max_lines: true
|
||||
- section_exceeds_lines: 150
|
||||
- parallel_agent_writes: true
|
||||
|
||||
visualization: |
|
||||
```mermaid
|
||||
|
|
@ -189,8 +212,10 @@ workflow:
|
|||
requires: pre_review_validation
|
||||
inputs:
|
||||
- story_file
|
||||
outputs:
|
||||
- arch_review_shard # Direct to shard: epic{N}.story{N}.arch-review.md
|
||||
checklist: story-dod-checklist.md
|
||||
notes: "REQUIRED: Use Task tool for execution - Round 1 - Architect validates technical design and architecture"
|
||||
notes: "REQUIRED: Use Task tool for execution - Round 1 - Architect validates technical design and architecture. Write results directly to architecture review shard for parallel processing."
|
||||
checklist_completion_tracking: true
|
||||
|
||||
- step: round1_business_review
|
||||
|
|
@ -199,8 +224,10 @@ workflow:
|
|||
requires: pre_review_validation
|
||||
inputs:
|
||||
- story_file
|
||||
outputs:
|
||||
- biz_review_shard # Direct to shard: epic{N}.story{N}.biz-review.md
|
||||
checklist: story-dod-checklist.md
|
||||
notes: "REQUIRED: Use Task tool for execution - Round 1 - Product Owner validates business alignment and value"
|
||||
notes: "REQUIRED: Use Task tool for execution - Round 1 - Product Owner validates business alignment and value. Write results directly to business review shard for parallel processing."
|
||||
checklist_completion_tracking: true
|
||||
|
||||
- step: round1_process_review
|
||||
|
|
@ -209,8 +236,10 @@ workflow:
|
|||
requires: pre_review_validation
|
||||
inputs:
|
||||
- story_file
|
||||
outputs:
|
||||
- proc_review_shard # Direct to shard: epic{N}.story{N}.proc-review.md
|
||||
checklist: story-dod-checklist.md
|
||||
notes: "REQUIRED: Use Task tool for execution - Round 1 - Scrum Master validates process compliance and DoD"
|
||||
notes: "REQUIRED: Use Task tool for execution - Round 1 - Scrum Master validates process compliance and DoD. Write results directly to process review shard for parallel processing."
|
||||
checklist_completion_tracking: true
|
||||
|
||||
- step: round1_qa_review
|
||||
|
|
@ -219,8 +248,10 @@ workflow:
|
|||
requires: pre_review_validation
|
||||
inputs:
|
||||
- story_file
|
||||
outputs:
|
||||
- qa_review_shard # Direct to shard: epic{N}.story{N}.qa-review.md
|
||||
checklist: story-dod-checklist.md
|
||||
notes: "REQUIRED: Use Task tool for execution - Round 1 - QA validates implementation quality and completeness"
|
||||
notes: "REQUIRED: Use Task tool for execution - Round 1 - QA validates implementation quality and completeness. Write results directly to QA review shard for parallel processing."
|
||||
checklist_completion_tracking: true
|
||||
|
||||
- step: round1_ux_review
|
||||
|
|
@ -229,8 +260,10 @@ workflow:
|
|||
requires: pre_review_validation
|
||||
inputs:
|
||||
- story_file
|
||||
outputs:
|
||||
- ux_review_shard # Direct to shard: epic{N}.story{N}.ux-review.md
|
||||
checklist: story-dod-checklist.md
|
||||
notes: "REQUIRED: Use Task tool for execution - Round 1 - UX Expert validates user experience and accessibility"
|
||||
notes: "REQUIRED: Use Task tool for execution - Round 1 - UX Expert validates user experience and accessibility. Write results directly to UX review shard for parallel processing."
|
||||
checklist_completion_tracking: true
|
||||
|
||||
- step: consolidate_feedback
|
||||
|
|
@ -238,22 +271,26 @@ workflow:
|
|||
action: consolidate-review-feedback
|
||||
requires: [round1_architecture_review, round1_business_review, round1_process_review, round1_qa_review, round1_ux_review]
|
||||
inputs:
|
||||
- story_file
|
||||
- architecture_feedback
|
||||
- business_feedback
|
||||
- process_feedback
|
||||
- qa_feedback
|
||||
- ux_feedback
|
||||
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."
|
||||
- story_file # Main story context
|
||||
- arch_review_shard # From architect review
|
||||
- biz_review_shard # From PO review
|
||||
- proc_review_shard # From SM review
|
||||
- qa_review_shard # From QA review
|
||||
- ux_review_shard # From UX review
|
||||
outputs:
|
||||
- consolidated_shard # Direct to shard: epic{N}.story{N}.consolidated.md
|
||||
notes: "REQUIRED: Use Task tool for execution - Scrum Master consolidates all review feedback from individual review shards with REQUIRED-FOR-COMPLETION/QUALITY-STANDARD/IMPROVEMENT/SCOPE-CREEP classification. Compare ALL feedback against original acceptance criteria to identify scope creep. Write consolidated results to dedicated shard."
|
||||
|
||||
- step: implement_fixes
|
||||
agent: dev
|
||||
action: implement-consolidated-fixes
|
||||
requires: consolidate_feedback
|
||||
inputs:
|
||||
- story_file
|
||||
- consolidated_feedback
|
||||
notes: "REQUIRED: Use Task tool for execution - Dev implements consolidated fixes and documents in story"
|
||||
- story_file # Main story context
|
||||
- consolidated_shard # From consolidation step
|
||||
outputs:
|
||||
- implementation_shard # Direct to shard: epic{N}.story{N}.implementation.md
|
||||
notes: "REQUIRED: Use Task tool for execution - Dev implements consolidated fixes from consolidated feedback shard and documents results in implementation fixes shard. Read consolidated feedback from dedicated shard."
|
||||
|
||||
- step: verify_quality_gates
|
||||
agent: dev
|
||||
|
|
@ -262,41 +299,47 @@ workflow:
|
|||
inputs:
|
||||
- story_file
|
||||
checklist: story-dod-checklist.md
|
||||
notes: "REQUIRED: Use Task tool for execution - Dev verifies all quality gates pass before architect review"
|
||||
notes: "REQUIRED: Use Task tool for execution - Dev verifies all quality gates pass before SM validation"
|
||||
checklist_completion_tracking: true
|
||||
|
||||
- step: validate_fixes
|
||||
agent: architect
|
||||
agent: sm
|
||||
action: validate-consolidated-fixes
|
||||
requires: verify_quality_gates
|
||||
inputs:
|
||||
- story_file
|
||||
- original_feedback
|
||||
- implemented_fixes
|
||||
notes: "REQUIRED: Use Task tool for execution - Architect validates fixes using story docs + browser MCP for UX changes"
|
||||
- story_file # Main story context
|
||||
- consolidated_shard # Original feedback from SM consolidation
|
||||
- implementation_shard # Implemented fixes
|
||||
outputs:
|
||||
- validation_shard # Direct to shard: epic{N}.story{N}.validation.md
|
||||
notes: "REQUIRED: Use Task tool for execution - SM validates that implemented fixes address consolidated feedback priorities and classification. Process compliance validation, not technical deep-dive."
|
||||
story_status_update: "Implementation Validated"
|
||||
|
||||
- step: capture_learning_triage
|
||||
agent: architect
|
||||
agent: sm
|
||||
action: capture-learning-triage
|
||||
requires: validate_fixes
|
||||
inputs:
|
||||
- story_file
|
||||
- review_feedback
|
||||
- implementation_fixes
|
||||
- quality_metrics
|
||||
notes: "REQUIRED: Use Task tool for execution - Extract and triage learnings into structured categories with priorities"
|
||||
- story_file # Main story context
|
||||
- consolidated_shard # Original consolidated feedback
|
||||
- implementation_shard # Implementation details
|
||||
- validation_shard # SM validation results
|
||||
outputs:
|
||||
- learning_shard # Direct to shard: epic{N}.story{N}.learning.md
|
||||
notes: "REQUIRED: Use Task tool for execution - SM extracts learnings from entire story implementation process with neutral perspective across all domains. Triage into structured categories with priorities."
|
||||
story_status_update: "Learning Extracted"
|
||||
|
||||
- step: party_mode_review
|
||||
agent: architect
|
||||
agent: sm
|
||||
action: party-mode-learning-review
|
||||
requires: capture_learning_triage
|
||||
inputs:
|
||||
- story_file
|
||||
- learning_triage_items
|
||||
collaborators: [po, sm, dev]
|
||||
notes: "REQUIRED: Use Task tool for execution - Architect-led collaborative team review of learning items with technical categorization consensus"
|
||||
- story_file # Main story context
|
||||
- learning_shard # Learning items from SM triage
|
||||
outputs:
|
||||
- review_shard # Direct to shard: epic{N}.story{N}.review.md
|
||||
collaborators: [architect, po, dev]
|
||||
notes: "REQUIRED: Use Task tool for execution - SM-facilitated collaborative team review of learning items with neutral facilitation. Architect provides key technical input. Build consensus on learning priorities and categorization."
|
||||
story_status_update: "Learning Reviewed"
|
||||
|
||||
- step: commit_and_prepare_pr
|
||||
|
|
@ -304,10 +347,12 @@ workflow:
|
|||
action: commit-and-prepare-pr
|
||||
requires: party_mode_review
|
||||
inputs:
|
||||
- story_file
|
||||
- learning_review_results
|
||||
- implementation_changes
|
||||
notes: "REQUIRED: Use Task tool for execution - Commit implementation with comprehensive context and prepare PR materials"
|
||||
- story_file # Main story context
|
||||
- review_shard # Learning review results
|
||||
- implementation_shard # Implementation changes
|
||||
outputs:
|
||||
- pr_context_shard # Direct to shard: epic{N}.story{N}.pr-context.md
|
||||
notes: "REQUIRED: Use Task tool for execution - Commit implementation and create PR context shard with comprehensive context. Read from dedicated shards for complete context."
|
||||
story_status_update: "Changes Committed"
|
||||
|
||||
- step: create_comprehensive_pr
|
||||
|
|
@ -315,10 +360,12 @@ workflow:
|
|||
action: create-comprehensive-pr
|
||||
requires: commit_and_prepare_pr
|
||||
inputs:
|
||||
- story_file
|
||||
- commit_information
|
||||
- pr_context
|
||||
notes: "REQUIRED: Use Task tool for execution - Create PR with business summary, technical changes, and learning extraction"
|
||||
- story_file # Main story context
|
||||
- pr_context_shard # PR context from commit step
|
||||
- review_shard # Learning insights
|
||||
outputs:
|
||||
- pr_info_shard # Direct to shard: epic{N}.story{N}.pr-info.md
|
||||
notes: "REQUIRED: Use Task tool for execution - Create PR from PR context shard with business summary, technical changes, and learning extraction. Write PR details to dedicated shard."
|
||||
story_status_update: "PR Created"
|
||||
|
||||
- step: update_epic_progress
|
||||
|
|
@ -326,11 +373,12 @@ workflow:
|
|||
action: update-epic-progress
|
||||
requires: create_comprehensive_pr
|
||||
inputs:
|
||||
- story_file
|
||||
- epic_number
|
||||
- pr_information
|
||||
- learning_items
|
||||
notes: "REQUIRED: Use Task tool for execution - Update epic progress tracking and schedule learning integration"
|
||||
- story_file # Main story context with epic number
|
||||
- pr_info_shard # PR details
|
||||
- review_shard # Learning items for integration
|
||||
outputs:
|
||||
- epic_file # Updated with story progress
|
||||
notes: "REQUIRED: Use Task tool for execution - Update epic progress tracking from story and dedicated shards. Schedule learning integration from learning review shard."
|
||||
story_status_update: "Done - Delivered"
|
||||
|
||||
- step: epic_retrospective
|
||||
|
|
@ -504,10 +552,10 @@ workflow:
|
|||
round1_reviews: "Pre-review passed. Conduct comprehensive Round 1 reviews (architecture, business, process, QA, UX)"
|
||||
consolidate: "Round 1 reviews complete. Consolidate all feedback with REQUIRED-FOR-COMPLETION/QUALITY-STANDARD/IMPROVEMENT classification"
|
||||
implement_fixes: "Feedback consolidated. Implement fixes and document changes in story"
|
||||
verify_gates: "Fixes implemented. Verify all quality gates pass before architect review"
|
||||
validate_fixes: "Quality gates passed. Validate fixes using story docs + browser MCP for UX changes"
|
||||
capture_learning: "Implementation validated. Extract learnings into structured categories with priorities and ownership"
|
||||
party_review: "Learning triage complete. Architect facilitates collaborative team review to achieve technical categorization consensus"
|
||||
verify_gates: "Fixes implemented. Verify all quality gates pass before SM validation"
|
||||
validate_fixes: "Quality gates passed. SM validates that fixes address consolidated feedback priorities and completion criteria"
|
||||
capture_learning: "Implementation validated. SM extracts learnings from entire story process with neutral perspective across all domains"
|
||||
party_review: "Learning triage complete. SM facilitates collaborative team review with architect providing key technical input to achieve consensus"
|
||||
commit_prepare: "Learning review complete. Commit implementation changes and prepare comprehensive PR context"
|
||||
create_pr: "Implementation committed. Create PR with business summary, technical changes, and learning extraction"
|
||||
update_epic: "PR created. Update epic progress tracking and schedule learning integration. Checking epic completion status for MANDATORY epic retrospective."
|
||||
|
|
|
|||
Loading…
Reference in New Issue