feat: add story implementation expansion pack
Add new expansion pack for story implementation functionality. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
2-gabadi
parent
6dca9cc5ba
commit
70585ede70
|
|
@ -0,0 +1,64 @@
|
|||
# epic-readiness-checklist.md
|
||||
|
||||
**Purpose**: Validate epic business readiness and dependencies before story creation
|
||||
**Agent**: po (Product Owner)
|
||||
**Phase**: Pre-Story Creation Validation
|
||||
|
||||
## Epic Business Readiness Validation
|
||||
|
||||
### Epic Existence & Status Verification
|
||||
- [ ] **Epic file exists**: `docs/epic{epic_number}.md` or alternative location confirmed
|
||||
- [ ] **Epic status approved**: Epic status is "Approved" (not Draft/In Progress/Review)
|
||||
- [ ] **Epic completion readiness**: Epic has clear business objectives and scope defined
|
||||
- [ ] **Epic format compliance**: Epic follows project template and documentation standards
|
||||
|
||||
### Epic Dependencies Assessment
|
||||
- [ ] **Prerequisite epics completed**: All prerequisite epics are marked "Done" or dependencies resolved
|
||||
- [ ] **No blocking dependencies**: No unresolved technical or business blockers identified for epic scope
|
||||
- [ ] **Resource availability**: Required team members and resources available for epic execution
|
||||
- [ ] **External dependencies clear**: Third-party services, APIs, or integrations ready if needed
|
||||
|
||||
### Epic Context Sufficiency Analysis
|
||||
- [ ] **Business goals clarity**: Epic provides sufficient context for meaningful story creation
|
||||
- [ ] **User journeys defined**: Business goals and user workflows are clearly articulated
|
||||
- [ ] **Success criteria specified**: Epic completion criteria and definition of done are explicit
|
||||
- [ ] **Acceptance boundaries**: Epic scope boundaries and out-of-scope items are clearly defined
|
||||
|
||||
### Story Creation Readiness
|
||||
- [ ] **Story numbering valid**: Requested story number does not conflict with existing stories
|
||||
- [ ] **Epic sequence logic**: Story fits logical sequence within epic roadmap and dependencies
|
||||
- [ ] **Story prerequisites met**: All prerequisite stories for requested story are completed
|
||||
- [ ] **Business context sufficient**: Epic provides enough detail for comprehensive story definition
|
||||
|
||||
### Business Value Validation
|
||||
- [ ] **Value proposition clear**: Epic business value and ROI rationale are explicitly documented
|
||||
- [ ] **Priority alignment**: Epic aligns with current business priorities and strategic objectives
|
||||
- [ ] **Stakeholder alignment**: Key stakeholders have reviewed and approved epic scope
|
||||
- [ ] **Risk assessment complete**: Known risks and mitigation strategies are documented
|
||||
|
||||
## Validation Outcomes
|
||||
|
||||
### If ALL checks pass:
|
||||
- **Status**: Epic ready for story creation
|
||||
- **Action**: Proceed with create_story workflow step
|
||||
- **Documentation**: Update story file with epic validation timestamp and PO approval
|
||||
|
||||
### If ANY check fails:
|
||||
- **Status**: Epic not ready for story creation
|
||||
- **Action**: HALT workflow and address identified issues
|
||||
- **Escalation**: Work with SM and stakeholders to resolve epic readiness blockers
|
||||
- **Documentation**: Document specific issues and required remediation steps
|
||||
|
||||
## Notes
|
||||
|
||||
- This checklist must be completed before any story creation begins
|
||||
- Focus on business readiness rather than technical implementation details
|
||||
- Epic validation ensures stories are created from well-defined, approved business context
|
||||
- Failed validation prevents wasted effort on premature or poorly defined stories
|
||||
|
||||
## Integration Points
|
||||
|
||||
- **Input from**: Epic files, previous story status, business stakeholder feedback
|
||||
- **Output to**: create_story workflow step (if validation passes)
|
||||
- **Dependencies**: Epic documentation standards, story numbering conventions
|
||||
- **Escalation**: SM for process issues, architect for technical dependencies
|
||||
|
|
@ -0,0 +1,136 @@
|
|||
# Story Approval Checklist (Product Owner)
|
||||
|
||||
## Purpose
|
||||
|
||||
Product Owner validation checklist to approve stories for development. This checklist ensures the story delivers business value, aligns with epic goals, and is ready for the development team.
|
||||
|
||||
[[LLM: INITIALIZATION INSTRUCTIONS - STORY APPROVAL VALIDATION
|
||||
|
||||
This checklist is for PRODUCT OWNERS to validate stories created by Scrum Master before development begins.
|
||||
|
||||
VALIDATION FOCUS:
|
||||
1. Business value and alignment
|
||||
2. User need satisfaction
|
||||
3. Acceptance criteria accuracy
|
||||
4. Scope appropriateness
|
||||
5. Development readiness
|
||||
|
||||
EXECUTION APPROACH:
|
||||
1. Review the story in context of its parent epic
|
||||
2. Validate from user/business perspective (not technical)
|
||||
3. Focus on "will this deliver the intended value?"
|
||||
4. Consider if this is the right story at the right time
|
||||
5. Ensure development team has clear success criteria
|
||||
|
||||
APPROVAL DECISION:
|
||||
- APPROVED: Story ready for development
|
||||
- CONDITIONAL: Minor changes needed before approval
|
||||
- REJECTED: Significant revision required]]
|
||||
|
||||
## Validation Criteria
|
||||
|
||||
### 1. BUSINESS VALUE ALIGNMENT
|
||||
|
||||
[[LLM: Verify the story actually solves a user problem and contributes to epic goals]]
|
||||
|
||||
- [ ] **User Story Clarity**: User story clearly articulates WHO, WHAT, and WHY
|
||||
- [ ] **Epic Alignment**: Story directly contributes to epic business objectives
|
||||
- [ ] **Value Proposition**: Clear business or user value from implementing this story
|
||||
- [ ] **User Need**: Addresses a real user need (not just technical convenience)
|
||||
|
||||
### 2. ACCEPTANCE CRITERIA VALIDATION
|
||||
|
||||
[[LLM: ACs must be testable and reflect actual business requirements, not just technical specs]]
|
||||
|
||||
- [ ] **Completeness**: ACs cover all essential functionality for the user story
|
||||
- [ ] **Business Accuracy**: ACs reflect actual business rules and user expectations
|
||||
- [ ] **Testability**: Each AC can be verified through user testing or business validation
|
||||
- [ ] **Clarity**: ACs are unambiguous and actionable for development team
|
||||
- [ ] **Measurability**: Success criteria are observable and measurable
|
||||
|
||||
### 3. SCOPE AND PRIORITY ASSESSMENT
|
||||
|
||||
[[LLM: Ensure story is right-sized and appropriately prioritized]]
|
||||
|
||||
- [ ] **MVP Alignment**: Story scope aligns with MVP boundaries (not over-engineered)
|
||||
- [ ] **Iteration Size**: Story can be completed in single development iteration
|
||||
- [ ] **Priority Justification**: Story priority is appropriate for current epic phase
|
||||
- [ ] **Dependency Clarity**: Prerequisites and dependencies are clearly identified
|
||||
- [ ] **Risk Assessment**: Business risk of implementing/not implementing is understood
|
||||
|
||||
### 4. USER EXPERIENCE CONSIDERATION
|
||||
|
||||
[[LLM: From user perspective, does this story make sense and add value?]]
|
||||
|
||||
- [ ] **User Journey**: Story fits logically into user workflow and journey
|
||||
- [ ] **Usability**: Implementation will result in intuitive user experience
|
||||
- [ ] **Edge Cases**: Important user scenarios and edge cases are considered
|
||||
- [ ] **Error Handling**: User-facing error scenarios are addressed in ACs
|
||||
|
||||
### 5. DEVELOPMENT READINESS
|
||||
|
||||
[[LLM: Development team has what they need to succeed]]
|
||||
|
||||
- [ ] **Requirements Clarity**: Development team will understand what to build
|
||||
- [ ] **Success Definition**: Clear definition of "done" from business perspective
|
||||
- [ ] **Stakeholder Availability**: PO available for clarification during development
|
||||
- [ ] **Acceptance Process**: Process for validating completed story is defined
|
||||
|
||||
## APPROVAL DECISION
|
||||
|
||||
[[LLM: STORY APPROVAL SUMMARY
|
||||
|
||||
Based on checklist validation, provide:
|
||||
|
||||
1. Approval Decision
|
||||
- APPROVED: Ready for development
|
||||
- CONDITIONAL: Specific changes needed (list them)
|
||||
- REJECTED: Major revision required (explain why)
|
||||
|
||||
2. Business Confidence
|
||||
- High: Very confident this delivers intended value
|
||||
- Medium: Some concerns but workable
|
||||
- Low: Significant value or alignment concerns
|
||||
|
||||
3. Key Issues (if any)
|
||||
- List specific problems found
|
||||
- Suggest concrete improvements
|
||||
- Identify any business risks
|
||||
|
||||
4. Approval Actions
|
||||
- If APPROVED: Update story status to "Approved"
|
||||
- If CONDITIONAL: Document required changes
|
||||
- If REJECTED: Document revision requirements
|
||||
|
||||
5. Next Steps
|
||||
- For approved stories: Proceed to development
|
||||
- For conditional: Return to SM with change requests
|
||||
- For rejected: Return to epic planning for revision]]
|
||||
|
||||
| Category | Status | Comments |
|
||||
|----------|--------|----------|
|
||||
| 1. Business Value Alignment | _TBD_ | |
|
||||
| 2. Acceptance Criteria Validation | _TBD_ | |
|
||||
| 3. Scope and Priority Assessment | _TBD_ | |
|
||||
| 4. User Experience Consideration | _TBD_ | |
|
||||
| 5. Development Readiness | _TBD_ | |
|
||||
|
||||
### Final Decision
|
||||
|
||||
- [ ] **APPROVED**: Story is ready for development (update status to "Approved")
|
||||
- [ ] **CONDITIONAL**: Story needs specific changes before approval (document below)
|
||||
- [ ] **REJECTED**: Story requires significant revision (return to epic planning)
|
||||
|
||||
### Issues and Required Changes
|
||||
|
||||
(Document any specific issues found and changes needed)
|
||||
|
||||
### Business Risk Assessment
|
||||
|
||||
- **Implementation Risk**: _[High/Medium/Low]_
|
||||
- **User Impact**: _[High/Medium/Low]_
|
||||
- **Business Value Confidence**: _[High/Medium/Low]_
|
||||
|
||||
### Approval Notes
|
||||
|
||||
(Optional: Additional context for development team or future reference)
|
||||
|
|
@ -0,0 +1,116 @@
|
|||
name: story-implementation
|
||||
version: 1.0.0
|
||||
description: >-
|
||||
Dual-variant story implementation with comprehensive validation.
|
||||
Simple: UI/content changes with validation (9 steps, 2-3 days)
|
||||
Standard: Feature implementation with comprehensive validation (15 steps, 4-5 days)
|
||||
Includes Task tool execution requirements.
|
||||
author: BMAD Development Team
|
||||
bmad_version: "4.0.0"
|
||||
|
||||
# Files included in this expansion pack
|
||||
files:
|
||||
workflows:
|
||||
- story-simple.yml
|
||||
- story-implementation.yml
|
||||
|
||||
tasks:
|
||||
- approve-story-for-development.md
|
||||
- setup-development-environment.md
|
||||
- implement-story-development.md
|
||||
- consolidate-review-feedback.md
|
||||
- implement-consolidated-fixes.md
|
||||
- validate-consolidated-fixes.md
|
||||
- capture-learning-triage.md
|
||||
- party-mode-learning-review.md
|
||||
- commit-and-prepare-pr.md
|
||||
- create-comprehensive-pr.md
|
||||
- update-epic-progress.md
|
||||
- epic-party-mode-retrospective.md
|
||||
|
||||
checklists:
|
||||
- story-approval-checklist.md
|
||||
- epic-readiness-checklist.md
|
||||
|
||||
# Dependencies on core BMAD components
|
||||
dependencies:
|
||||
core_agents:
|
||||
- sm
|
||||
- po
|
||||
- infra-devops-platform
|
||||
- dev
|
||||
- architect
|
||||
- qa
|
||||
- ux-expert
|
||||
core_tasks:
|
||||
- create-next-story
|
||||
- execute-checklist
|
||||
- implement-story-development
|
||||
core_checklists:
|
||||
- story-draft-checklist.md
|
||||
- architect-checklist.md
|
||||
- po-master-checklist.md
|
||||
- story-dod-checklist.md
|
||||
core_templates:
|
||||
- story-tmpl.md
|
||||
|
||||
# No additional data files required from user
|
||||
required_data: []
|
||||
|
||||
# No template variables needed - core tasks handle validation
|
||||
|
||||
# Post-install message
|
||||
post_install_message: |
|
||||
Story Implementation Pack v1.0.0 ready!
|
||||
|
||||
Phase 1: Story Preparation (Epic → Story Ready for Development)
|
||||
Phase 2: Implementation (Story Development with Validation)
|
||||
Phase 3: Quality Review (Comprehensive Round 1 + Efficient Round 2+)
|
||||
Phase 4: Learning Extraction (Triage + Collaborative Review)
|
||||
Phase 5: Commit and PR Preparation (Context Generation)
|
||||
Phase 6: PR Creation and Epic Progress (Delivery + Tracking)
|
||||
|
||||
Features:
|
||||
- Epic validation before story creation
|
||||
- Project-agnostic code generation and build tool integration
|
||||
- Round 1: Comprehensive reviews (Architecture, Business, Process, QA, UX)
|
||||
- Feedback consolidation with REQUIRED-FOR-COMPLETION/QUALITY-STANDARD/IMPROVEMENT classification
|
||||
- Round 2+: Efficient architect-only validation with browser MCP testing
|
||||
- Story status tracking throughout workflow (Draft → Approved → In Progress → Verified → Review → Done → Delivered)
|
||||
- Story-based documentation for evidence and tracking
|
||||
- Learning extraction with structured triage system (6 categories)
|
||||
- Party mode collaborative learning review with team consensus
|
||||
- Comprehensive PR creation with business context and learning insights
|
||||
- Epic progress tracking with learning integration
|
||||
- LLM-optimized documentation with token limits and structured brevity
|
||||
|
||||
Learning Categories:
|
||||
- ARCH_CHANGE: Architecture improvements and technical debt
|
||||
- FUTURE_EPIC: Epic candidates and feature opportunities
|
||||
- URGENT_FIX: Critical issues requiring immediate attention
|
||||
- PROCESS_IMPROVEMENT: Development workflow enhancements
|
||||
- TOOLING: Infrastructure and automation improvements
|
||||
- KNOWLEDGE_GAP: Team training and skill development needs
|
||||
|
||||
Epic Retrospective Features:
|
||||
- Automatic trigger when epic reaches 100% completion
|
||||
- Multi-agent collaborative analysis (SM, Architect, PO, Dev, UX-Expert)
|
||||
- Party mode consensus building for epic insights
|
||||
- Strategic pattern identification across all epic stories
|
||||
- Action items for next epic with clear ownership
|
||||
- Epic knowledge base creation for future reference
|
||||
- Seamless integration with final story PR
|
||||
|
||||
Usage:
|
||||
*workflow story-simple epic_number=X story_number=Y # 9 steps, streamlined for simple changes
|
||||
*workflow story-implementation epic_number=X story_number=Y # 15 steps, comprehensive for features
|
||||
|
||||
Workflow Selection Guide:
|
||||
- story-simple: UI/UX improvements, content updates, simple bug fixes, minor backend changes
|
||||
- story-implementation: New features, business logic, database changes, cross-system integration
|
||||
|
||||
⚠️ Both workflows include complexity validation warnings to ensure appropriate selection.
|
||||
All workflow steps require Task tool execution for proper expansion pack compliance.
|
||||
|
||||
Built on core bmad-method components for maximum reliability.
|
||||
Complete learning extraction and epic progress tracking in both variants.
|
||||
|
|
@ -0,0 +1,86 @@
|
|||
# Story Implementation Expansion Pack Plan
|
||||
|
||||
## Overview
|
||||
|
||||
- Pack Name: story-implementation
|
||||
- Description: End-to-end story implementation workflow from epic context to PR-ready delivery
|
||||
- Target Domain: Agile development teams using epic-driven methodology
|
||||
- Initial Scope: Phase 1 - Story Preparation (Epic → Story Ready for Development)
|
||||
|
||||
## Problem Statement
|
||||
|
||||
Current workflow (`.claude/commands/implement-story.md`) is overly complex and not functioning effectively. Need a progressive, testable approach that can be built incrementally.
|
||||
|
||||
## Phase 1 Implementation (Current Priority)
|
||||
|
||||
Transform epic context and story number into a complete, validated story ready for development.
|
||||
|
||||
### Components to Create
|
||||
|
||||
#### Agents
|
||||
|
||||
- [ ] story-implementation-orchestrator (REQUIRED: Custom BMAD orchestrator for Phase 1)
|
||||
|
||||
#### Tasks
|
||||
|
||||
- [ ] validate-epic-for-story (referenced by: po via BatchTask)
|
||||
- [ ] create-story-from-epic (referenced by: sm via BatchTask)
|
||||
- [ ] validate-story-quality (referenced by: po via BatchTask)
|
||||
- [ ] setup-development-environment (referenced by: infra-devops-platform via BatchTask)
|
||||
|
||||
#### Templates
|
||||
|
||||
- [ ] Uses existing story-tmpl.md from bmad-core (no new templates needed for Phase 1)
|
||||
|
||||
#### Checklists
|
||||
|
||||
- [ ] Uses existing story-draft-checklist.md from bmad-core (no new checklists needed for Phase 1)
|
||||
|
||||
#### Dependencies on Core BMAD Components
|
||||
|
||||
- [ ] po (Product Owner agent)
|
||||
- [ ] sm (Scrum Master agent)
|
||||
- [ ] infra-devops-platform (DevOps Infrastructure agent)
|
||||
- [ ] story-tmpl.md (Story template)
|
||||
- [ ] story-draft-checklist.md (Story draft checklist)
|
||||
|
||||
#### Data Files Required from User
|
||||
|
||||
- [ ] Epic files in docs/epic{number}.md format
|
||||
- [ ] Existing bmad-core configuration (no additional data files needed for Phase 1)
|
||||
|
||||
## Future Phases (Not Implemented Yet)
|
||||
|
||||
### Phase 2: Implementation (TDD Development)
|
||||
- Backend/Frontend development coordination
|
||||
- Checkpoint-based progress tracking
|
||||
- Quality gates integration
|
||||
|
||||
### Phase 3: Quality Review
|
||||
- Architecture review
|
||||
- Business validation
|
||||
- Process compliance
|
||||
|
||||
### Phase 4: PR Creation & Delivery
|
||||
- Final validation
|
||||
- PR generation
|
||||
- Documentation updates
|
||||
|
||||
## Success Criteria for Phase 1
|
||||
|
||||
- [ ] Orchestrator can execute epic → story preparation workflow
|
||||
- [ ] All 4 tasks work independently and in sequence
|
||||
- [ ] Story status progresses from non-existent → "Approved for Development"
|
||||
- [ ] Environment is validated and ready for implementation
|
||||
- [ ] Can be executed via `*story-implementation-orchestrator` command
|
||||
|
||||
## Approval
|
||||
|
||||
User approval received: [ ] Yes
|
||||
|
||||
## Notes
|
||||
|
||||
- Starting with Phase 1 only to enable iterative development
|
||||
- Reusing existing tasks created during workflow development
|
||||
- Progressive expansion approach allows testing and refinement
|
||||
- Each phase will be added incrementally based on learnings from previous phases
|
||||
|
|
@ -0,0 +1,112 @@
|
|||
# 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 (`docs/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 `story-approval-checklist.md` as validation framework
|
||||
- Systematically evaluate each checklist category:
|
||||
- Business Value Alignment
|
||||
- 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**:
|
||||
- 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"
|
||||
- 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)
|
||||
- Business confidence level (High/Medium/Low)
|
||||
- Key findings or concerns
|
||||
- Required changes (if conditional)
|
||||
- Risk assessment
|
||||
- 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
|
||||
- Required changes documented if story needs revision
|
||||
- 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
|
||||
|
|
@ -0,0 +1,150 @@
|
|||
# Capture Learning Triage
|
||||
|
||||
## Task Overview
|
||||
**Agent:** architect
|
||||
**Action Type:** learning-triage
|
||||
**Duration:** 10-15 minutes
|
||||
**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
|
||||
|
||||
## 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]`
|
||||
- **Priority:** HIGH/MEDIUM/LOW
|
||||
- **Timeline:** Current epic / Next epic / Technical debt backlog
|
||||
|
||||
### FUTURE_EPIC (Epic Candidate Features)
|
||||
- **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
|
||||
- **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]`
|
||||
- **Priority:** HIGH/MEDIUM/LOW
|
||||
- **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]`
|
||||
- **Priority:** HIGH/MEDIUM/LOW
|
||||
- **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]`
|
||||
- **Priority:** HIGH/MEDIUM/LOW
|
||||
- **Timeline:** Current sprint / Next sprint / Long-term development
|
||||
|
||||
## Execution Steps
|
||||
|
||||
### Step 1: Review Implementation Context
|
||||
```
|
||||
CONTEXT_REVIEW:
|
||||
- Story complexity: [SIMPLE/MODERATE/COMPLEX]
|
||||
- Implementation time: [Actual vs Estimated]
|
||||
- Quality gate failures: [Count and types]
|
||||
- Review rounds required: [1/2/3+]
|
||||
- Key technical challenges: [List top 3]
|
||||
```
|
||||
|
||||
### Step 2: Extract Learning Items
|
||||
For each category, scan implementation evidence:
|
||||
- Review feedback 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
|
||||
Medium Priority: Improves quality/efficiency, affects future work
|
||||
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
|
||||
- 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
|
||||
- [ ] Immediate actions (URGENT_FIX) clearly identified
|
||||
- [ ] Future epic candidates captured with business value
|
||||
- [ ] 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
|
||||
- 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
|
||||
|
|
@ -0,0 +1,238 @@
|
|||
# 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
|
||||
|
||||
## 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
|
||||
- Ready state for PR creation
|
||||
|
||||
## Execution Steps
|
||||
|
||||
### Step 1: Pre-Commit Validation (2 minutes)
|
||||
```
|
||||
PRE_COMMIT_CHECKLIST:
|
||||
- [ ] All quality gates passing
|
||||
- [ ] 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
|
||||
|
||||
Story: Epic {epic_number}, Story {story_number}
|
||||
Type: [feature/enhancement/fix/refactor]
|
||||
|
||||
Implementation Summary:
|
||||
- [Key change 1 - max 50 tokens]
|
||||
- [Key change 2 - max 50 tokens]
|
||||
- [Key change 3 - max 50 tokens]
|
||||
|
||||
Quality Gates: [PASS/FAIL counts]
|
||||
Review Rounds: [1/2/3+]
|
||||
Learning Items: [X items captured]
|
||||
|
||||
Business Value: [Brief description - max 100 tokens]
|
||||
Technical Impact: [Brief description - max 100 tokens]
|
||||
|
||||
Generated with Claude Code
|
||||
Co-Authored-By: Claude <noreply@anthropic.com>
|
||||
```
|
||||
|
||||
### Step 3: Commit Implementation (1 minute)
|
||||
```bash
|
||||
# Add all story-related changes
|
||||
git add .
|
||||
|
||||
# Create commit with comprehensive message
|
||||
git commit -m "$(cat <<'EOF'
|
||||
[Epic{epic_number}-Story{story_number}] {brief_summary}
|
||||
|
||||
Story: Epic {epic_number}, Story {story_number}
|
||||
Type: {change_type}
|
||||
|
||||
Implementation Summary:
|
||||
- {key_change_1}
|
||||
- {key_change_2}
|
||||
- {key_change_3}
|
||||
|
||||
Quality Gates: {pass_count} PASS, {fail_count} FAIL
|
||||
Review Rounds: {review_rounds}
|
||||
Learning Items: {learning_count} items captured
|
||||
|
||||
Business Value: {business_value_summary}
|
||||
Technical Impact: {technical_impact_summary}
|
||||
|
||||
🤖 Generated with [Claude Code](https://claude.ai/code)
|
||||
|
||||
Co-Authored-By: Claude <noreply@anthropic.com>
|
||||
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}
|
||||
**Type:** {change_type}
|
||||
**Complexity:** {SIMPLE/MODERATE/COMPLEX}
|
||||
**Epic Status:** {IN_PROGRESS/COMPLETE}
|
||||
**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
|
||||
- Multi-agent retrospective scheduled with: SM (facilitator), Architect, PO, Dev, UX-Expert
|
||||
- Strategic insights and next epic preparation action items to be generated
|
||||
|
||||
**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
|
||||
|
||||
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
|
||||
- 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
|
||||
- [ ] Story file updated with commit information
|
||||
- [ ] All quality gates confirmed passing before commit
|
||||
- [ ] 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
|
||||
- **Quality:** Include quality gate results and review metrics
|
||||
- **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
|
||||
|
|
@ -0,0 +1,189 @@
|
|||
# Consolidate Review Feedback
|
||||
|
||||
## Task Overview
|
||||
**Agent:** architect
|
||||
**Action Type:** feedback-consolidation
|
||||
**Duration:** 10-15 minutes
|
||||
**LLM-Optimized:** Token-efficient structured consolidation
|
||||
|
||||
## Purpose
|
||||
Consolidate feedback from all Round 1 reviews into prioritized action plan with REQUIRED-FOR-COMPLETION/QUALITY-STANDARD/IMPROVEMENT classification for efficient implementation.
|
||||
|
||||
## 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
|
||||
- Overlap elimination and action sequencing
|
||||
|
||||
## 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
|
||||
- `qa_feedback` (object): Results from QA review
|
||||
- `ux_feedback` (object): Results from UX expert review
|
||||
|
||||
## Outputs
|
||||
|
||||
- `consolidated_feedback` (object): Unified feedback with priority classification
|
||||
- `implementation_plan` (string): Step-by-step fix implementation sequence
|
||||
- `story_file` (string): Updated story file with consolidation summary
|
||||
|
||||
## Instructions
|
||||
|
||||
### Step 1: Pre-Consolidation Analysis
|
||||
|
||||
**Feedback Source Review:**
|
||||
- Architecture: Technical design and implementation issues
|
||||
- Business: Requirements and value delivery gaps
|
||||
- Process: DoD compliance and workflow adherence
|
||||
- QA: Quality standards and testing coverage
|
||||
- UX: User experience and accessibility concerns
|
||||
|
||||
**Scope Assessment:**
|
||||
```
|
||||
FEEDBACK_ANALYSIS:
|
||||
- Total items: [count]
|
||||
- Overlapping issues: [count]
|
||||
- Conflicts identified: [count]
|
||||
- Implementation effort: [HIGH/MEDIUM/LOW]
|
||||
```
|
||||
|
||||
### Step 2: Priority Classification
|
||||
|
||||
**REQUIRED-FOR-COMPLETION** (Blocks story completion):
|
||||
- Acceptance criteria gaps
|
||||
- Critical functionality breaks
|
||||
- Business rule violations
|
||||
- User journey blockers
|
||||
- Core feature missing/incorrect
|
||||
|
||||
**QUALITY-STANDARD** (Project standard violations):
|
||||
- Test coverage below requirements
|
||||
- Code quality standard violations
|
||||
- Performance threshold failures
|
||||
- Required accessibility non-compliance
|
||||
- Security scan failures
|
||||
- Architecture pattern violations
|
||||
|
||||
**IMPROVEMENT** (Future enhancement opportunities):
|
||||
- Code optimization suggestions
|
||||
- UX polish improvements
|
||||
- Technical debt reduction
|
||||
- Extended functionality ideas
|
||||
- Documentation enhancements
|
||||
- Process improvements
|
||||
|
||||
**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
|
||||
- Reviewer disagreements → Architecture principles guide
|
||||
|
||||
### Step 4: Implementation Sequencing (3-4 minutes)
|
||||
**Sequencing Rules:**
|
||||
1. REQUIRED-FOR-COMPLETION (dependency order)
|
||||
2. QUALITY-STANDARD (grouped by domain)
|
||||
3. Dependencies: Backend → Frontend → Integration
|
||||
4. Validation checkpoints after major changes
|
||||
|
||||
**Implementation Groups:**
|
||||
```
|
||||
PHASE_1: [Critical fixes] - Est: [time]
|
||||
PHASE_2: [Quality standards] - Est: [time]
|
||||
VALIDATION: [Testing approach] - Est: [time]
|
||||
```
|
||||
|
||||
### Step 5: Documentation Update (2 minutes)
|
||||
Update story file with:
|
||||
|
||||
```markdown
|
||||
## Review Consolidation Summary
|
||||
**Architect:** [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)
|
||||
- QA: [PASS/ISSUES] ([X] items)
|
||||
- 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
|
||||
|
||||
### Implementation Sequence
|
||||
**Phase 1:** [Critical fixes] - Est: [time] - Items: [count]
|
||||
**Phase 2:** [Quality fixes] - Est: [time] - Items: [count]
|
||||
**Validation:** [Testing approach] - Est: [time]
|
||||
|
||||
**Total Effort:** [time estimate] | **Priority Items:** [count]
|
||||
```
|
||||
|
||||
7. **Create implementation roadmap**
|
||||
- Provide clear, actionable steps for developer
|
||||
- Include specific technical requirements
|
||||
- Note any coordination needs with other agents
|
||||
- Specify validation criteria for each fix
|
||||
|
||||
## Success Criteria
|
||||
- [ ] All 5 review streams analyzed and categorized
|
||||
- [ ] Conflicts resolved with clear rationale
|
||||
- [ ] Priority classification complete (3 categories)
|
||||
- [ ] Implementation sequence with time estimates
|
||||
- [ ] Story file updated with structured summary
|
||||
- [ ] Action items under 50 tokens each
|
||||
- [ ] Ready for efficient developer implementation
|
||||
|
||||
## Failure Conditions
|
||||
|
||||
- Conflicting feedback not resolved
|
||||
- Missing critical review input
|
||||
- Unclear or unactionable implementation steps
|
||||
- Priority classification incomplete
|
||||
- Implementation sequence illogical
|
||||
|
||||
## 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
|
||||
4. Proceed with best available information
|
||||
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
|
||||
- Evidence-based priority prevents subjective interpretation
|
||||
- Phase sequencing optimizes implementation efficiency
|
||||
- Clear success criteria enable objective validation
|
||||
|
||||
## Integration Points
|
||||
|
||||
- **Input from:** Round 1 reviews (architect, po, sm, qa, ux-expert)
|
||||
- **Output to:** implement-consolidated-fixes task (dev agent)
|
||||
- **Dependencies:** All Round 1 review checklists must be complete
|
||||
- **Validation:** Next phase will validate using story docs + Playwright MCP
|
||||
|
|
@ -0,0 +1,243 @@
|
|||
# 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
|
||||
|
||||
## 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
|
||||
- All validation evidence and quality metrics
|
||||
- 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
|
||||
- Story file updated with PR information
|
||||
|
||||
## Execution Steps
|
||||
|
||||
### Step 1: Generate PR Title (1 minute)
|
||||
```
|
||||
PR_TITLE_FORMAT:
|
||||
[Epic{epic_number}.{story_number}] {business_focused_title}
|
||||
|
||||
Examples:
|
||||
- [Epic1.Story3] Add batch priority selector for dispatch optimization
|
||||
- [Epic2.Story1] Implement mobile scanning workflow for operations
|
||||
- [Epic3.Story2] Enhance order validation with QR code integration
|
||||
```
|
||||
|
||||
### 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}
|
||||
**User Impact:** {user_impact_description}
|
||||
**Success Metrics:** {success_criteria}
|
||||
**Epic Status:** {IN_PROGRESS/COMPLETE}
|
||||
|
||||
### Key Business Outcomes
|
||||
- ✅ {business_outcome_1}
|
||||
- ✅ {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)
|
||||
|
||||
**Total:** {file_count} files, {total_lines} lines changed
|
||||
|
||||
## 📚 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
|
||||
- **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)
|
||||
- **Fix Implementation:** ✅ COMPLETE
|
||||
- **Final Validation:** ✅ COMPLETE
|
||||
|
||||
### Story DoD Compliance
|
||||
- **Business Requirements:** ✅ MET
|
||||
- **Technical Requirements:** ✅ MET
|
||||
- **Quality Standards:** ✅ MET
|
||||
- **Documentation:** ✅ COMPLETE
|
||||
- **Learning Extraction:** ✅ COMPLETE
|
||||
|
||||
## 🔍 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_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}
|
||||
- **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
|
||||
|
||||
{epic_completion_celebration}
|
||||
|
||||
🤖 Generated with [Claude Code](https://claude.ai/code)
|
||||
```
|
||||
|
||||
### 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}
|
||||
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 {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
|
||||
- Validation evidence: ✅ COMPLETE
|
||||
- Review assignments: ✅ COMPLETE
|
||||
- Epic retrospective context: ✅ COMPLETE (MANDATORY if epic 100% complete)
|
||||
|
||||
**Final Status:** Story Implementation → PR Ready for Delivery
|
||||
**Epic Retrospective Status:** {MANDATORY_TRIGGERED/NOT_APPLICABLE}
|
||||
```
|
||||
|
||||
## Success Criteria
|
||||
- [ ] PR created with comprehensive business and technical context
|
||||
- [ ] Epic completion status prominently displayed
|
||||
- [ ] Epic retrospective context included (if triggered)
|
||||
- [ ] Learning items prominently featured with action assignments
|
||||
- [ ] Validation evidence clearly documented
|
||||
- [ ] Appropriate reviewers assigned based on learning categories
|
||||
- [ ] Story file updated with PR information
|
||||
- [ ] 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
|
||||
- **Evidence-Based:** Include objective validation proof
|
||||
- **Action-Oriented:** Clear next steps and ownership
|
||||
- **Comprehensive:** All context needed for informed review
|
||||
- **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)
|
||||
- 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
|
||||
|
|
@ -0,0 +1,316 @@
|
|||
# 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
|
||||
|
||||
## 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
|
||||
- Epic metrics and timeline data
|
||||
- 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
|
||||
- Process improvements for future epics
|
||||
- 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
|
||||
- **dev** (Developer) - Implementation patterns and technical debt
|
||||
- **ux-expert** (UX Expert) - User experience patterns and design insights
|
||||
|
||||
## Execution Steps
|
||||
|
||||
### Step 1: Epic Data Consolidation (10 minutes)
|
||||
**Agent:** sm (Epic Retrospective Facilitator)
|
||||
Lead epic data consolidation with strategic focus on process insights:
|
||||
|
||||
```markdown
|
||||
# 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
|
||||
- **Review Rounds:** {average_review_rounds}
|
||||
- **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_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
|
||||
- **{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
|
||||
### 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}
|
||||
- Stories: {story_references}
|
||||
|
||||
3. **{success_factor_3}** | Votes: {vote_count}/5 | Priority: {HIGH/MEDIUM/LOW}
|
||||
- Evidence: {supporting_evidence}
|
||||
- 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}
|
||||
|
||||
3. **{improvement_3}** | Votes: {vote_count}/5 | Impact: {HIGH/MEDIUM/LOW}
|
||||
- Root Cause: {cause_analysis}
|
||||
- Stories Affected: {story_references}
|
||||
```
|
||||
|
||||
#### 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
|
||||
- **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
|
||||
- **Templates:** {template_items} templates need creation
|
||||
```
|
||||
|
||||
### Step 5: Epic Retrospective Artifacts (5 minutes)
|
||||
**Agent:** sm (Strategic Documentation Owner)
|
||||
|
||||
Generate final epic retrospective artifacts:
|
||||
|
||||
```markdown
|
||||
# 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_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}
|
||||
|
||||
**Epic Retrospective Status:** COMPLETE
|
||||
**Team Consensus:** ACHIEVED
|
||||
**Next Epic Readiness:** {READY/NEEDS_PREP/BLOCKED}
|
||||
```
|
||||
|
||||
## 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
|
||||
- [ ] Action items defined with clear ownership and timelines
|
||||
- [ ] Epic knowledge base created for future reference
|
||||
- [ ] 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
|
||||
- **Time Boxing:** 5 minutes per major decision point
|
||||
- **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
|
||||
|
|
@ -0,0 +1,232 @@
|
|||
# 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
|
||||
|
||||
## 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
|
||||
- Quality gate maintenance throughout process
|
||||
|
||||
## Inputs
|
||||
|
||||
### Required
|
||||
- `story_file` (string): Path to the story file with consolidation summary
|
||||
- `consolidated_feedback` (object): Prioritized feedback from consolidation task
|
||||
|
||||
## Outputs
|
||||
|
||||
- `implementation_status` (string): "Complete" | "Partial" | "Blocked"
|
||||
- `story_file` (string): Updated story file with implementation details
|
||||
- `fixes_summary` (string): Summary of changes implemented
|
||||
|
||||
## Instructions
|
||||
|
||||
### Step 1: Pre-Implementation Analysis (3-5 minutes)
|
||||
|
||||
**Consolidation Review:**
|
||||
```
|
||||
FIX_ANALYSIS:
|
||||
- REQUIRED items: [count]
|
||||
- QUALITY-STANDARD items: [count]
|
||||
- Implementation phases: [count]
|
||||
- Estimated effort: [time]
|
||||
- Dependencies identified: [list]
|
||||
```
|
||||
|
||||
**Technical Scope Assessment:**
|
||||
- Backend changes: [YES/NO] - [component list]
|
||||
- Frontend changes: [YES/NO] - [component list]
|
||||
- Integration points: [list]
|
||||
- Quality gates impact: [NONE/MINOR/MAJOR]
|
||||
- Testing approach: [unit/integration/e2e]
|
||||
|
||||
### 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]
|
||||
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
|
||||
|
||||
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
|
||||
- Visual design corrections
|
||||
|
||||
### 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
|
||||
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
|
||||
- Test critical user journeys still work
|
||||
- Ensure story acceptance criteria still met
|
||||
- Document any remaining concerns or blockers
|
||||
|
||||
8. **Prepare for architect validation**
|
||||
- Ensure story documentation is complete and clear
|
||||
- Note any UX changes that require Playwright validation
|
||||
- Document any technical decisions made during implementation
|
||||
- Flag any items that couldn't be completed and why
|
||||
|
||||
## Success Criteria
|
||||
|
||||
- All REQUIRED-FOR-COMPLETION and QUALITY-STANDARD fixes implemented according to plan
|
||||
- Project quality gates continue to pass
|
||||
- Story file updated with comprehensive implementation details
|
||||
- No regressions in existing functionality
|
||||
- Ready for architect validation with clear documentation
|
||||
|
||||
## Failure Conditions
|
||||
|
||||
- REQUIRED-FOR-COMPLETION or QUALITY-STANDARD fixes incomplete or incorrect
|
||||
- Project quality gates failing after implementation
|
||||
- Insufficient documentation of changes
|
||||
- Existing functionality broken by fixes
|
||||
- Critical technical blockers preventing completion
|
||||
|
||||
## 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
|
||||
4. Recommend next steps (escalation, scope change, etc.)
|
||||
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
|
||||
4. Document any ongoing quality issues
|
||||
5. Do not proceed to validation until gates pass
|
||||
|
||||
## Notes
|
||||
|
||||
- Focus exclusively on REQUIRED-FOR-COMPLETION and QUALITY-STANDARD items
|
||||
- IMPROVEMENT items should be documented but not implemented
|
||||
- Story documentation is critical for subsequent architect validation
|
||||
- UX changes requiring server interaction should be clearly marked
|
||||
- Maintain project coding standards and conventions throughout
|
||||
|
||||
## Integration Points
|
||||
|
||||
- **Input from:** consolidate-review-feedback 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
|
||||
|
|
@ -0,0 +1,284 @@
|
|||
# implement-story-development
|
||||
|
||||
**Agent:** dev
|
||||
**Type:** BatchTask
|
||||
|
||||
## Purpose
|
||||
|
||||
Complete comprehensive story implementation including code development, testing, and quality validation with project-agnostic build tool integration and story status management.
|
||||
|
||||
## 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.)
|
||||
- Maintains project quality gates throughout implementation
|
||||
- Updates story status and documentation
|
||||
|
||||
## 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
|
||||
|
||||
## Outputs
|
||||
|
||||
- `implementation_status` (string): "Complete" | "Partial" | "Blocked"
|
||||
- `story_file` (string): Updated story file with implementation details
|
||||
- `code_changes` (string): Summary of code modifications made
|
||||
- `quality_gates_status` (string): Status of project quality validation
|
||||
|
||||
## Instructions
|
||||
|
||||
### 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
|
||||
|
||||
### 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
|
||||
- Test the functionality works correctly
|
||||
- Document implementation approach in 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
|
||||
- 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
|
||||
- Validate performance meets requirements
|
||||
|
||||
### 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]
|
||||
```
|
||||
|
||||
8. **Verify implementation completeness**
|
||||
- Confirm all acceptance criteria implemented
|
||||
- Ensure all project quality gates pass
|
||||
- Verify no regressions in existing functionality
|
||||
- Test critical user journeys still work
|
||||
- Document any remaining work or blockers
|
||||
|
||||
## Success Criteria
|
||||
|
||||
- All story acceptance criteria implemented and tested
|
||||
- Project-defined quality gates executed and passing
|
||||
- Code generation tools executed when applicable
|
||||
- Project configuration properly detected and utilized
|
||||
- Comprehensive test coverage per project standards
|
||||
- Story file updated with implementation details and status
|
||||
- No regressions in existing functionality
|
||||
- Ready for review validation
|
||||
|
||||
## Failure Conditions
|
||||
|
||||
- Acceptance criteria incomplete or incorrectly implemented
|
||||
- Project-agnostic quality gates failing (auto-detected toolchain validation)
|
||||
- Code generation not executed when needed (project-specific tools)
|
||||
- Project type detection failed and no fallback validation performed
|
||||
- Insufficient test coverage per project standards
|
||||
- Existing functionality broken by implementation
|
||||
- Story documentation incomplete or unclear
|
||||
|
||||
## 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
|
||||
4. Recommend next steps (escalation, scope change, technical research)
|
||||
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
|
||||
- Capture error messages and exit codes
|
||||
2. **Fix issues systematically following project standards**
|
||||
- Use project-appropriate fixing tools (auto-formatters, linters)
|
||||
- Follow project-specific conventions and standards
|
||||
3. **Re-run quality gates after each fix**
|
||||
- Use same auto-detected commands for consistency
|
||||
- Try alternative commands if primary ones fail
|
||||
4. **Document any persistent quality issues and resolutions**
|
||||
- Note if project-specific tools are missing or misconfigured
|
||||
- Document any manual workarounds used
|
||||
5. **Apply fallback validation if standard tools unavailable**
|
||||
- Use manual code review processes
|
||||
- Check for project-specific CI/CD validation
|
||||
- Document inability to use standard toolchain
|
||||
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
|
||||
2. **Check project-specific generation command syntax**
|
||||
- Verify auto-detected generation commands are correct
|
||||
- Try alternative generation commands for the project type
|
||||
- Check project documentation for custom generation scripts
|
||||
3. **Ensure generation tools are properly installed and configured**
|
||||
- Verify project-specific generators are available
|
||||
- Check for missing dependencies or configuration files
|
||||
- Try installing missing tools if permissions allow
|
||||
4. **Document generation issues and manual alternatives**
|
||||
- Record specific project type and generation tools attempted
|
||||
- Document any manual generation steps performed
|
||||
- Note if generation was skipped and why
|
||||
5. **Escalate to infrastructure team if generation tools broken**
|
||||
- Provide specific project type and toolchain information
|
||||
- Include error messages and attempted commands
|
||||
- Suggest infrastructure improvements for project type support
|
||||
|
||||
## Notes
|
||||
|
||||
- Adapt build commands to project's actual build system (not just npm)
|
||||
- Code generation should be executed after any backend/API schema changes
|
||||
- Story status should be updated from "Approved" to "In Progress" to "Ready for Review"
|
||||
- Focus on project quality standards - not all projects have same validation requirements
|
||||
- Document technical decisions for future reference and learning
|
||||
|
||||
## Integration Points
|
||||
|
||||
- **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
|
||||
|
|
@ -0,0 +1,199 @@
|
|||
# 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
|
||||
|
||||
## 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
|
||||
- Updated story file with ## Learning Review Results
|
||||
|
||||
## Multi-Agent Collaboration Protocol
|
||||
|
||||
### Pre-Review Setup
|
||||
**Architect (Facilitator):**
|
||||
```
|
||||
SETUP:
|
||||
- Review learning triage items across categories
|
||||
- Identify high-priority items requiring discussion
|
||||
- Determine appropriate participant involvement
|
||||
- Prepare collaborative decision-making approach
|
||||
```
|
||||
|
||||
### 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
|
||||
- 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
|
||||
- Majority vote determines final priority
|
||||
- Ties resolved by story complexity impact
|
||||
```
|
||||
|
||||
#### 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
|
||||
|
||||
### 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
|
||||
|
||||
## 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]
|
||||
|
||||
NEXT_SPRINT_ACTIONS:
|
||||
- [Action] - [Owner] - [Sprint Planning Item] - [Dependencies]
|
||||
|
||||
BACKLOG_ITEMS:
|
||||
- [Action] - [Owner] - [Epic/Initiative] - [Prerequisites]
|
||||
```
|
||||
|
||||
### Team Consensus Summary
|
||||
```
|
||||
CONSENSUS_METRICS:
|
||||
- Total items reviewed: [X]
|
||||
- High priority consensus: [X items]
|
||||
- Priority disagreements resolved: [X items]
|
||||
- Immediate actions identified: [X items]
|
||||
- Next sprint actions: [X items]
|
||||
- Backlog items: [X items]
|
||||
```
|
||||
|
||||
## Success Criteria
|
||||
- [ ] All learning triage items reviewed by relevant domain experts
|
||||
- [ ] Priority conflicts resolved through team consensus
|
||||
- [ ] Clear ownership assigned to each action item
|
||||
- [ ] Immediate actions identified with specific timelines
|
||||
- [ ] Next sprint integration planned
|
||||
- [ ] 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
|
||||
- [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
|
||||
- Ensure all agents contribute to their domain items with technical context
|
||||
- Document technical decisions and categorizations in real-time
|
||||
- Escalate unresolved technical conflicts to architecture review
|
||||
- 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
|
||||
|
|
@ -0,0 +1,62 @@
|
|||
# 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 development services are running (database, redis, backend, frontend)
|
||||
- Check service connectivity and responsiveness
|
||||
- Validate port availability and configuration
|
||||
- Ensure no service conflicts or failures
|
||||
|
||||
### 2. Development Dependencies
|
||||
- Verify all required dependencies are installed
|
||||
- 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
|
||||
- Verify authorization rules are working
|
||||
- Check security configurations are properly set
|
||||
- Validate API access and permissions
|
||||
|
||||
### 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)
|
||||
- Authentication working with test credentials
|
||||
- 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
|
||||
|
|
@ -0,0 +1,246 @@
|
|||
# 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
|
||||
|
||||
## 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
|
||||
- Next story readiness assessment
|
||||
|
||||
## 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
|
||||
- [ ] Epic business value delivered
|
||||
|
||||
**Epic Completion Status:** {completion_percentage}%
|
||||
**Epic Retrospective Status:** {APPLICABLE/NOT_APPLICABLE}
|
||||
```
|
||||
|
||||
### 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}
|
||||
- **Projected Completion:** {projected_completion_date}
|
||||
- **Days Remaining:** {days_remaining}
|
||||
```
|
||||
|
||||
### 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
|
||||
- **Fix Cycles:** Average {avg_fix_cycles} per story
|
||||
|
||||
**Epic Retrospective Ready:** {YES/NO}
|
||||
**All Story Data Consolidated:** {YES/NO}
|
||||
**Retrospective Status:** {READY/NOT_READY}
|
||||
```
|
||||
|
||||
### 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}
|
||||
- **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
|
||||
- **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
|
||||
- [ ] **Team Capacity:** {available_capacity} story points available
|
||||
- [ ] **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)
|
||||
- [ ] Learning extraction scheduled and tracked in epic context
|
||||
- [ ] Epic health indicators reflect current status
|
||||
- [ ] Next story readiness assessed (if epic not complete)
|
||||
- [ ] Epic metrics updated with completion data
|
||||
- [ ] Future epic candidates properly tracked
|
||||
- [ ] 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})
|
||||
- **Next Story:** Story {next_number} - {readiness_status/N_A_IF_COMPLETE}
|
||||
- **Epic Health:** {GREEN/YELLOW/RED}
|
||||
- **Epic Retrospective:** {MANDATORY_AUTO_TRIGGERED/NOT_REQUIRED}
|
||||
- **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}
|
||||
- [ ] Conduct Epic Retrospective - {MANDATORY_AUTO_TRIGGERED/NOT_REQUIRED}
|
||||
```
|
||||
|
||||
## 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
|
||||
Current: Story {story_number} ✅ | Next: Story {next_number} {status_icon}
|
||||
Health: {health_color} | Learning: {learning_items} items | ETA: {completion_date}
|
||||
```
|
||||
|
||||
## Learning Integration Benefits
|
||||
- **Continuous Improvement:** Each story informs the next
|
||||
- **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
|
||||
|
|
@ -0,0 +1,320 @@
|
|||
# validate-consolidated-fixes
|
||||
|
||||
**Agent:** architect
|
||||
**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.
|
||||
|
||||
## 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
|
||||
- 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
|
||||
|
||||
## Outputs
|
||||
|
||||
- `validation_status` (string): "APPROVED" | "NEEDS_FIXES" | "BLOCKED"
|
||||
- `validation_results` (object): Detailed validation findings
|
||||
- `additional_feedback` (string): Specific guidance for any remaining issues
|
||||
- `story_file` (string): Updated story file with validation results
|
||||
|
||||
## Instructions
|
||||
|
||||
### Pre-Validation Analysis
|
||||
|
||||
1. **Review implementation documentation**
|
||||
- Read story file implementation section thoroughly
|
||||
- Compare implemented fixes against original consolidated feedback
|
||||
- Identify any MVP-BLOCKING items that were not addressed
|
||||
- Note any technical decisions or changes made during implementation
|
||||
|
||||
2. **Assess validation approach needed**
|
||||
- Identify which fixes require technical code review
|
||||
- Determine which changes need UX validation via Playwright
|
||||
- Note any business logic changes requiring functional testing
|
||||
- Plan validation sequence based on dependencies
|
||||
|
||||
### 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 MVP boundaries respected
|
||||
|
||||
5. **Validate UX fixes using browser testing tools**
|
||||
|
||||
**When UX validation needed:**
|
||||
- Visual interface changes described in story
|
||||
- User interaction flow modifications
|
||||
- Accessibility improvements requiring testing
|
||||
- Design consistency updates
|
||||
|
||||
**Comprehensive Browser MCP Testing Protocol:**
|
||||
|
||||
**Phase 1: Environment Setup**
|
||||
- Launch browser MCP session (prefer Playwright MCP for full automation)
|
||||
- Use dedicated incognito/private browser context for clean state
|
||||
- Clear all cache, cookies, and local storage before testing
|
||||
- Set viewport to standard desktop resolution (1920x1080)
|
||||
- Configure browser for debugging (enable console logging)
|
||||
|
||||
**Phase 2: Pre-Testing Validation**
|
||||
- Navigate to application base URL
|
||||
- Verify application loads without errors (check console)
|
||||
- Take baseline screenshot 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
|
||||
|
||||
**Phase 4: Accessibility & Responsive Testing**
|
||||
- Test keyboard navigation for new/changed interactive elements
|
||||
- Verify ARIA labels and roles if accessibility improvements documented
|
||||
- Test responsive behavior at mobile (375px), tablet (768px), desktop (1920px) viewports
|
||||
- Validate color contrast and text readability for visual changes
|
||||
|
||||
**Phase 5: Cross-Browser Compatibility (if critical changes)**
|
||||
- Repeat core tests in Chrome, Firefox, and Safari (via MCP if supported)
|
||||
- Document any browser-specific issues discovered
|
||||
- Capture comparative screenshots across browsers for visual changes
|
||||
|
||||
**Phase 6: Evidence Documentation and Cleanup**
|
||||
- Save all screenshots to temporary validation directory with descriptive filenames (feature_state_timestamp.png)
|
||||
- Record any console errors or warnings encountered
|
||||
- Document specific browser MCP commands used for reproducibility
|
||||
- Create testing summary with pass/fail status for each tested component
|
||||
- Note: All browser testing artifacts are temporary and will be cleaned up after validation completion
|
||||
|
||||
**Browser MCP Session Management:**
|
||||
- Maintain single browser context throughout testing for consistency
|
||||
- Use page reload between major test sections to ensure clean state
|
||||
- Close and reopen browser context if session becomes unstable
|
||||
- Document MCP tool version and configuration used
|
||||
- Clean up browser 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
|
||||
- No permanent files created during browser testing process
|
||||
|
||||
### 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
|
||||
- [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]
|
||||
|
||||
- [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]
|
||||
|
||||
**Cross-Browser Compatibility:** [Tested/Not Required]
|
||||
- Chrome: [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 POST-MVP 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
|
||||
- Provide technical guidance for resolution
|
||||
|
||||
## Success Criteria
|
||||
|
||||
- All REQUIRED-FOR-COMPLETION and QUALITY-STANDARD fixes validated against original requirements
|
||||
- UX changes comprehensively tested via browser MCP with evidence documentation
|
||||
- Browser MCP testing includes interaction validation, visual verification, accessibility checks, and responsive testing
|
||||
- Cross-browser compatibility validated for critical changes (Chrome, Firefox, Safari)
|
||||
- Quality gates confirmed passing with specific validation evidence
|
||||
- Screenshot evidence captured and properly documented for all UI changes
|
||||
- Browser MCP session properly managed with clean state testing throughout
|
||||
- Clear validation decision made (APPROVED/NEEDS_FIXES/BLOCKED) with comprehensive rationale
|
||||
- Story documentation updated with detailed validation results including browser MCP findings
|
||||
- Next steps clearly communicated with specific actionable guidance
|
||||
|
||||
## Failure Conditions
|
||||
|
||||
- Unable to validate fixes due to insufficient documentation
|
||||
- Browser MCP testing fails for UX changes
|
||||
- Critical regressions discovered during validation
|
||||
- Original requirements misunderstood in implementation
|
||||
- Technical blockers prevent completion
|
||||
|
||||
## 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
|
||||
- Engage with development team for application-specific testing guidance
|
||||
- Consider scope adjustment if UX changes cannot be properly validated via available MCP tools
|
||||
|
||||
If validation reveals new issues:
|
||||
1. Classify as MVP-BLOCKING vs POST-MVP
|
||||
2. Provide clear guidance for resolution
|
||||
3. Update feedback for next implementation cycle
|
||||
4. Consider if scope adjustment needed
|
||||
|
||||
## Notes
|
||||
|
||||
- This task serves as the single validation gate for efficient iterations
|
||||
- Focus on validating against original consolidated feedback
|
||||
- Use browser MCP tools (Playwright MCP/Puppeteer MCP/similar) for UX changes requiring server interaction
|
||||
- Story documentation quality is critical for effective validation
|
||||
- Maintain positive, constructive feedback for development team
|
||||
|
||||
## Integration Points
|
||||
|
||||
- **Input from:** implement-consolidated-fixes task (dev agent)
|
||||
- **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
|
||||
|
|
@ -0,0 +1,517 @@
|
|||
workflow:
|
||||
id: story-implementation
|
||||
name: Story Implementation - Epic to PR Ready
|
||||
description: >-
|
||||
Complete story implementation workflow from epic context to PR delivery with learning extraction and MANDATORY epic retrospectives.
|
||||
Phase 1: Story Preparation (Epic + Story Number → Story Ready for Development)
|
||||
Phase 2: Implementation (Story Development with Validation)
|
||||
Phase 3: Quality Review (Architecture, Business, and QA Validation)
|
||||
Phase 4: Learning Extraction (Triage + Collaborative Review)
|
||||
Phase 5: Commit and PR Preparation (Context Generation)
|
||||
Phase 6: PR Creation and Epic Progress (Delivery + Tracking)
|
||||
Phase 7: Epic Retrospective (MANDATORY when epic reaches 100% completion)
|
||||
type: story-implementation
|
||||
|
||||
visualization: |
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Epic + Story Number] --> A1{PO: Validate Epic<br/>Readiness}
|
||||
A1 -->|Pass| B[SM: Create Story]
|
||||
A1 -->|Fail| A2[PO: Address Epic Issues<br/>max 3 retries]
|
||||
A2 --> A1
|
||||
B --> C{SM: Validate Draft}
|
||||
C -->|Pass| D{PO: Approve Story}
|
||||
C -->|Fail| C2[SM: Revise Story<br/>max 3 retries]
|
||||
C2 --> C
|
||||
|
||||
D -->|Pass| E[Infra: Setup Environment]
|
||||
D -->|Fail| D2[PO: Clarify Requirements<br/>max 3 retries]
|
||||
D2 --> D
|
||||
|
||||
E --> F[Dev: Implement Story<br/>with quality gates]
|
||||
F --> G{Dev: Pre-Review Validation<br/>quality gates + DoD}
|
||||
G -->|Pass| H[Round 1 Reviews<br/>Parallel]
|
||||
G -->|Fail| G2[Dev: Fix Issues<br/>max 5 retries]
|
||||
G2 --> G
|
||||
|
||||
H --> H1[Architect Review]
|
||||
H --> H2[Business Review]
|
||||
H --> H3[Process Review]
|
||||
H --> H4[QA Review]
|
||||
H --> H5[UX Review]
|
||||
|
||||
H1 --> I[Architect: Consolidate<br/>All Feedback]
|
||||
H2 --> I
|
||||
H3 --> I
|
||||
H4 --> I
|
||||
H5 --> I
|
||||
|
||||
I --> J[Dev: Implement<br/>Consolidated Fixes]
|
||||
J --> J2{Dev: Verify<br/>Quality Gates}
|
||||
J2 -->|Pass| K{Architect: Validate<br/>Fixes + Playwright}
|
||||
J2 -->|Fail| J3[Dev: Fix Quality Issues<br/>max 3 retries]
|
||||
J3 --> J2
|
||||
|
||||
K -->|Pass| L[Arch: Learning<br/>Triage]
|
||||
K -->|Fail| K2[Dev: Additional Fixes<br/>max 3 retries]
|
||||
K2 --> J2
|
||||
|
||||
L --> M[SM: Party Mode<br/>Learning Review]
|
||||
M --> N[Dev: Commit &<br/>Prepare PR Context]
|
||||
N --> O[PO: Create<br/>Comprehensive PR]
|
||||
O --> P[SM: Update<br/>Epic Progress]
|
||||
P --> P1{Epic Complete?<br/>100% Status Check}
|
||||
P1 -->|Yes| R[SM: Epic Retrospective<br/>MANDATORY Multi-Agent]
|
||||
P1 -->|No| Q[Story: Complete<br/>PR Delivered]
|
||||
R --> Q
|
||||
|
||||
%% Styling
|
||||
classDef phase1 fill:#e1f5fe
|
||||
classDef phase2 fill:#f3e5f5
|
||||
classDef phase3 fill:#e8f5e8
|
||||
classDef phase4 fill:#fff8e1
|
||||
classDef phase5 fill:#f1f8e9
|
||||
classDef phase6 fill:#fce4ec
|
||||
classDef phase7 fill:#e3f2fd
|
||||
classDef failure fill:#ffebee
|
||||
classDef decision fill:#fff3e0
|
||||
classDef parallel fill:#f0f4f8
|
||||
|
||||
class A1,B,E phase1
|
||||
class F,G phase2
|
||||
class H,H1,H2,H3,H4,H5,I,J,J2,K phase3
|
||||
class L,M phase4
|
||||
class N phase5
|
||||
class O,P,P1,Q phase6
|
||||
class R phase7
|
||||
class A2,C2,D2,G2,J3,K2 failure
|
||||
class A1,C,D,G,J2,K decision
|
||||
class H1,H2,H3,H4,H5 parallel
|
||||
```
|
||||
|
||||
inputs:
|
||||
epic_number:
|
||||
type: string
|
||||
description: The epic number (e.g., "1", "2", "3")
|
||||
required: true
|
||||
story_number:
|
||||
type: string
|
||||
description: The story number within the epic (e.g., "1", "2", "3")
|
||||
required: true
|
||||
|
||||
outputs:
|
||||
story_file:
|
||||
type: string
|
||||
description: Path to the created and approved story file
|
||||
format: "docs/stories/epic{epic_number}.story{story_number}.story.md"
|
||||
story_status:
|
||||
type: string
|
||||
description: Final story status
|
||||
expected: "Done"
|
||||
implementation_status:
|
||||
type: string
|
||||
description: Implementation completion status
|
||||
expected: "Complete"
|
||||
|
||||
steps:
|
||||
- step: validate_epic
|
||||
agent: po
|
||||
action: execute-checklist
|
||||
inputs:
|
||||
- epic_number
|
||||
checklist: epic-readiness-checklist.md
|
||||
notes: "REQUIRED: Use Task tool for execution - Validate epic business readiness and dependencies before story creation"
|
||||
story_status_update: "N/A - No story exists yet"
|
||||
|
||||
- step: create_story
|
||||
agent: sm
|
||||
action: create-next-story
|
||||
requires: validate_epic
|
||||
inputs:
|
||||
- epic_number
|
||||
- story_number
|
||||
notes: "REQUIRED: Use Task tool for execution - Create comprehensive story from epic context using existing bmad-core task"
|
||||
story_status_update: "Draft"
|
||||
|
||||
- step: validate_story_draft
|
||||
agent: sm
|
||||
action: execute-checklist
|
||||
requires: create_story
|
||||
inputs:
|
||||
- story_file
|
||||
checklist: story-draft-checklist.md
|
||||
notes: "REQUIRED: Use Task tool for execution - Validate story draft quality and completeness using bmad-core checklist"
|
||||
checklist_completion_tracking: true
|
||||
|
||||
- step: po_approval
|
||||
agent: po
|
||||
action: approve-story-for-development
|
||||
requires: validate_story_draft
|
||||
inputs:
|
||||
- story_file
|
||||
- epic_number
|
||||
notes: "REQUIRED: Use Task tool for execution - Product Owner validates business value and approves for development"
|
||||
story_status_update: "Approved"
|
||||
|
||||
- step: environment_setup
|
||||
agent: infra-devops-platform
|
||||
action: setup-development-environment
|
||||
requires: po_approval
|
||||
inputs:
|
||||
- story_file
|
||||
notes: "REQUIRED: Use Task tool for execution - Ensure development environment ready for story implementation"
|
||||
|
||||
- step: implement_story
|
||||
agent: dev
|
||||
action: implement-story-development
|
||||
requires: environment_setup
|
||||
inputs:
|
||||
- story_file
|
||||
- epic_number
|
||||
- story_number
|
||||
notes: "REQUIRED: Use Task tool for execution - Complete story implementation with validation (includes project quality gates)"
|
||||
story_status_update: "In Progress"
|
||||
|
||||
- step: pre_review_validation
|
||||
agent: dev
|
||||
action: execute-checklist
|
||||
requires: implement_story
|
||||
inputs:
|
||||
- story_file
|
||||
checklist: story-dod-checklist.md
|
||||
notes: "REQUIRED: Use Task tool for execution - Final validation before reviews - ensures project quality gates pass"
|
||||
story_status_update: "Review"
|
||||
checklist_completion_tracking: true
|
||||
|
||||
- step: round1_architecture_review
|
||||
agent: architect
|
||||
action: execute-checklist
|
||||
requires: pre_review_validation
|
||||
inputs:
|
||||
- story_file
|
||||
checklist: story-dod-checklist.md
|
||||
notes: "REQUIRED: Use Task tool for execution - Round 1 - Architect validates technical design and architecture"
|
||||
checklist_completion_tracking: true
|
||||
|
||||
- step: round1_business_review
|
||||
agent: po
|
||||
action: execute-checklist
|
||||
requires: pre_review_validation
|
||||
inputs:
|
||||
- story_file
|
||||
checklist: story-dod-checklist.md
|
||||
notes: "REQUIRED: Use Task tool for execution - Round 1 - Product Owner validates business alignment and value"
|
||||
checklist_completion_tracking: true
|
||||
|
||||
- step: round1_process_review
|
||||
agent: sm
|
||||
action: execute-checklist
|
||||
requires: pre_review_validation
|
||||
inputs:
|
||||
- story_file
|
||||
checklist: story-dod-checklist.md
|
||||
notes: "REQUIRED: Use Task tool for execution - Round 1 - Scrum Master validates process compliance and DoD"
|
||||
checklist_completion_tracking: true
|
||||
|
||||
- step: round1_qa_review
|
||||
agent: qa
|
||||
action: execute-checklist
|
||||
requires: pre_review_validation
|
||||
inputs:
|
||||
- story_file
|
||||
checklist: story-dod-checklist.md
|
||||
notes: "REQUIRED: Use Task tool for execution - Round 1 - QA validates implementation quality and completeness"
|
||||
checklist_completion_tracking: true
|
||||
|
||||
- step: round1_ux_review
|
||||
agent: ux-expert
|
||||
action: execute-checklist
|
||||
requires: pre_review_validation
|
||||
inputs:
|
||||
- story_file
|
||||
checklist: story-dod-checklist.md
|
||||
notes: "REQUIRED: Use Task tool for execution - Round 1 - UX Expert validates user experience and accessibility"
|
||||
checklist_completion_tracking: true
|
||||
|
||||
- step: consolidate_feedback
|
||||
agent: architect
|
||||
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 - Architect consolidates all review feedback with REQUIRED-FOR-COMPLETION/QUALITY-STANDARD/IMPROVEMENT classification"
|
||||
|
||||
- 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"
|
||||
|
||||
- step: verify_quality_gates
|
||||
agent: dev
|
||||
action: execute-checklist
|
||||
requires: implement_fixes
|
||||
inputs:
|
||||
- story_file
|
||||
checklist: story-dod-checklist.md
|
||||
notes: "REQUIRED: Use Task tool for execution - Dev verifies all quality gates pass before architect review"
|
||||
checklist_completion_tracking: true
|
||||
|
||||
- step: validate_fixes
|
||||
agent: architect
|
||||
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_status_update: "Implementation Validated"
|
||||
|
||||
- step: capture_learning_triage
|
||||
agent: architect
|
||||
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_status_update: "Learning Extracted"
|
||||
|
||||
- step: party_mode_review
|
||||
agent: architect
|
||||
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_status_update: "Learning Reviewed"
|
||||
|
||||
- step: commit_and_prepare_pr
|
||||
agent: dev
|
||||
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_status_update: "Changes Committed"
|
||||
|
||||
- step: create_comprehensive_pr
|
||||
agent: po
|
||||
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_status_update: "PR Created"
|
||||
|
||||
- step: update_epic_progress
|
||||
agent: sm
|
||||
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_status_update: "Done - Delivered"
|
||||
|
||||
- step: epic_retrospective
|
||||
agent: sm
|
||||
action: epic-party-mode-retrospective
|
||||
requires: update_epic_progress
|
||||
inputs:
|
||||
- epic_number
|
||||
- epic_completion_status
|
||||
- all_story_files
|
||||
- consolidated_learning_items
|
||||
- epic_metrics
|
||||
condition: epic_completion_status == "100%"
|
||||
collaborators: [architect, po, dev, ux-expert]
|
||||
notes: "REQUIRED: Use Task tool for execution - MANDATORY: Epic retrospective triggered automatically when epic reaches 100% completion"
|
||||
story_status_update: "Epic Complete - Retrospective Done"
|
||||
|
||||
success_criteria:
|
||||
- Epic readiness validated and approved for story creation
|
||||
- Epic validated and story created following template standards
|
||||
- Story draft quality validated by Scrum Master
|
||||
- Business value validated and approved by Product Owner
|
||||
- Technical environment ready for development
|
||||
- Story implementation completed with all validations passing
|
||||
- Pre-review validation confirms project quality gates pass
|
||||
- Round 1 comprehensive reviews completed (architecture, business, process, QA, UX)
|
||||
- Review feedback consolidated with REQUIRED-FOR-COMPLETION/QUALITY-STANDARD/IMPROVEMENT classification
|
||||
- Consolidated fixes implemented and documented in story
|
||||
- Quality gates verification confirms all technical validation passes
|
||||
- Architect validates all fixes using story documentation and testing
|
||||
- Learning extraction completed with structured triage and team review
|
||||
- Implementation committed with comprehensive context
|
||||
- PR created with business summary, technical changes, and learning insights
|
||||
- Epic progress updated with story completion and learning integration
|
||||
- MANDATORY: Epic retrospective executed when epic reaches 100% completion
|
||||
- Epic-level strategic insights and patterns identified through multi-agent collaboration
|
||||
- Next epic preparation actions defined with clear ownership
|
||||
- Story status updated to "Done - Delivered" ("Epic Complete - Retrospective Done" if epic complete)
|
||||
|
||||
failure_handling:
|
||||
- halt_on_failure: true
|
||||
- Each step must complete successfully before proceeding
|
||||
- Failed steps should be retried after addressing issues
|
||||
|
||||
retry_protocols:
|
||||
epic_validation_failure:
|
||||
- Issue: "Epic not ready for story creation (missing approval, dependencies, context)"
|
||||
- Action: "PO addresses epic readiness issues (approval, dependencies, business context)"
|
||||
- Retry: "Re-run validate_epic after epic issues resolved"
|
||||
- Max_retries: 3
|
||||
|
||||
sm_validation_failure:
|
||||
- Issue: "Story draft quality fails validation"
|
||||
- Action: "SM revises story based on checklist feedback"
|
||||
- Retry: "Re-run validate_story_draft after corrections"
|
||||
- Max_retries: 3
|
||||
|
||||
po_approval_failure:
|
||||
- Issue: "Business value or approval fails"
|
||||
- Action: "PO clarifies requirements or updates story"
|
||||
- Retry: "Re-run po_approval after business clarification"
|
||||
- Max_retries: 3
|
||||
|
||||
pre_review_failure:
|
||||
- Issue: "Project quality gates fail or DoD checklist incomplete"
|
||||
- Action: "Dev fixes technical issues and quality problems"
|
||||
- Retry: "Re-run pre_review_validation after fixes"
|
||||
- Max_retries: 5
|
||||
|
||||
round1_reviews_failure:
|
||||
- Issue: "Any Round 1 review fails (architecture, business, QA, UX)"
|
||||
- Action: "Proceed to consolidation - Architect will classify as MVP-BLOCKING or not"
|
||||
- Retry: "No retry at individual review level"
|
||||
- Notes: "All feedback flows to consolidation regardless of pass/fail"
|
||||
|
||||
consolidation_failure:
|
||||
- Issue: "Feedback consolidation fails or is incomplete"
|
||||
- Action: "Architect re-analyzes review feedback and creates clear action plan"
|
||||
- Retry: "Re-run consolidate_feedback after analysis"
|
||||
- Max_retries: 2
|
||||
|
||||
quality_gates_failure:
|
||||
- Issue: "Quality gates fail after implementing fixes"
|
||||
- Action: "Dev fixes technical issues (tests, linting, etc.)"
|
||||
- Retry: "Re-run implement_fixes → verify_quality_gates cycle"
|
||||
- Max_retries: 3
|
||||
- Notes: "Must pass all project quality gates before architect review"
|
||||
|
||||
fixes_validation_failure:
|
||||
- Issue: "Architect finds fixes incomplete or incorrect"
|
||||
- Action: "Dev implements additional fixes based on specific feedback"
|
||||
- Retry: "Re-run implement_fixes → verify_quality_gates → validate_fixes cycle"
|
||||
- Max_retries: 3
|
||||
- Notes: "Each retry includes quality gate verification + browser MCP validation"
|
||||
|
||||
learning_triage_failure:
|
||||
- Issue: "Learning extraction incomplete or poorly categorized"
|
||||
- Action: "Architect re-analyzes implementation context and feedback patterns"
|
||||
- Retry: "Re-run capture_learning_triage with improved analysis"
|
||||
- Max_retries: 2
|
||||
- Notes: "Focus on actionable learning items with clear ownership"
|
||||
|
||||
learning_review_failure:
|
||||
- Issue: "Team consensus not achieved on learning priorities"
|
||||
- Action: "SM facilitates additional discussion and conflict resolution"
|
||||
- Retry: "Re-run party_mode_review with refined facilitation"
|
||||
- Max_retries: 2
|
||||
- Notes: "Use voting protocol and time-boxing to achieve consensus"
|
||||
|
||||
commit_preparation_failure:
|
||||
- Issue: "Commit fails or PR context incomplete"
|
||||
- Action: "Dev addresses git issues and completes context preparation"
|
||||
- Retry: "Re-run commit_and_prepare_pr after resolving issues"
|
||||
- Max_retries: 3
|
||||
- Notes: "Ensure all quality gates pass before commit"
|
||||
|
||||
pr_creation_failure:
|
||||
- Issue: "PR creation fails or context incomplete"
|
||||
- Action: "PO addresses GitHub/PR platform issues and completes description"
|
||||
- Retry: "Re-run create_comprehensive_pr after resolving platform issues"
|
||||
- Max_retries: 3
|
||||
- Notes: "Ensure comprehensive business and technical context"
|
||||
|
||||
epic_progress_failure:
|
||||
- Issue: "Epic progress update fails or tracking incomplete"
|
||||
- Action: "SM addresses epic file issues and completes progress tracking"
|
||||
- Retry: "Re-run update_epic_progress after resolving tracking issues"
|
||||
- Max_retries: 2
|
||||
- Notes: "Ensure learning integration and next story readiness assessment"
|
||||
|
||||
dependencies:
|
||||
core_bmad_agents:
|
||||
- sm (Scrum Master)
|
||||
- po (Product Owner)
|
||||
- infra-devops-platform (DevOps Infrastructure)
|
||||
- dev (Developer)
|
||||
- architect (Technical Architect)
|
||||
- qa (Quality Assurance)
|
||||
- ux-expert (UX Expert)
|
||||
core_bmad_tasks:
|
||||
- create-next-story
|
||||
- execute-checklist
|
||||
- implement-story-development
|
||||
core_bmad_checklists:
|
||||
- story-draft-checklist.md
|
||||
- architect-checklist.md
|
||||
- po-master-checklist.md
|
||||
- story-dod-checklist.md
|
||||
expansion_tasks:
|
||||
- approve-story-for-development
|
||||
- setup-development-environment
|
||||
- consolidate-review-feedback
|
||||
- implement-consolidated-fixes
|
||||
- validate-consolidated-fixes
|
||||
- capture-learning-triage
|
||||
- party-mode-learning-review
|
||||
- commit-and-prepare-pr
|
||||
- create-comprehensive-pr
|
||||
- update-epic-progress
|
||||
- epic-party-mode-retrospective
|
||||
expansion_checklists:
|
||||
- story-approval-checklist.md
|
||||
- epic-readiness-checklist.md
|
||||
|
||||
handoff_prompts:
|
||||
po_validate_epic: "Validate epic {epic_number} readiness for story creation - check approval status, dependencies, and business context"
|
||||
sm_create_story: "Create story {epic_number}.{story_number} using epic context and bmad-core story template"
|
||||
sm_validate_draft: "Validate story draft quality using story-draft-checklist before PO review"
|
||||
po_approval: "Validate business value and approve story {epic_number}.{story_number} for development"
|
||||
infra_setup: "Story approved. Setup and validate development environment for implementation"
|
||||
dev_implement: "Environment ready. Implement story {epic_number}.{story_number} with validation (project quality gates required)"
|
||||
pre_review: "Implementation complete. Run final validation before reviews - ensure project quality gates pass"
|
||||
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"
|
||||
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."
|
||||
epic_retrospective: "Epic {epic_number} complete (100%). SM MUST facilitate multi-agent retrospective for strategic process insights and next epic preparation. This is MANDATORY and integral to the process."
|
||||
workflow_complete: "Story {epic_number}.{story_number} delivered. Epic retrospective status: {COMPLETED/NOT_TRIGGERED} based on epic completion (100% triggers MANDATORY retrospective)."
|
||||
|
|
@ -0,0 +1,310 @@
|
|||
workflow:
|
||||
id: story-simple
|
||||
name: Simple Story - UX/Content/Minor Changes
|
||||
description: >-
|
||||
Streamlined workflow for UI improvements, content changes, simple bug fixes, and minor backend adjustments.
|
||||
Optimized for changes that don't require comprehensive cross-specialist validation.
|
||||
Includes complexity validation warnings to ensure appropriate workflow selection.
|
||||
type: story-simple
|
||||
|
||||
visualization: |
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Story Number] --> A1{PO: Story Already<br/>Approved?}
|
||||
A1 -->|Yes| B[Dev: Implement Story]
|
||||
A1 -->|No| A2[PO: Approve Story<br/>Skip Epic if <7 days]
|
||||
A2 --> B
|
||||
|
||||
B --> C{Dev: Pre-Review<br/>Validation DoD}
|
||||
C -->|Pass| D[Architect: Review<br/>Technical Design]
|
||||
C -->|Fail| C2[Dev: Fix Issues<br/>max 3 retries]
|
||||
C2 --> C
|
||||
|
||||
D -->|Issues Found| E[Dev: Implement<br/>Architect Fixes]
|
||||
D -->|Pass| F[Architect: Learning<br/>Triage Capture]
|
||||
E --> E2{Dev: Validate Fixes}
|
||||
E2 -->|Pass| F
|
||||
E2 -->|Fail| E3[Dev: Additional Fixes<br/>max 2 retries]
|
||||
E3 --> E2
|
||||
|
||||
F --> G[Dev: Commit &<br/>Prepare PR Context]
|
||||
G --> H[SM: Update<br/>Epic Progress]
|
||||
H --> I[PO: Create<br/>Comprehensive PR]
|
||||
I --> J[Story: Complete<br/>PR Delivered]
|
||||
|
||||
%% Styling
|
||||
classDef simple fill:#e1f5fe
|
||||
classDef validation fill:#fff3e0
|
||||
classDef implementation fill:#f3e5f5
|
||||
classDef delivery fill:#e8f5e8
|
||||
|
||||
class A1,A2 simple
|
||||
class C,D,E,E2 validation
|
||||
class B,E,E3 implementation
|
||||
class F,G,H,I,J delivery
|
||||
```
|
||||
|
||||
inputs:
|
||||
epic_number:
|
||||
type: string
|
||||
description: The epic number (e.g., "1", "2", "3")
|
||||
required: true
|
||||
story_number:
|
||||
type: string
|
||||
description: The story number within the epic (e.g., "1", "2", "3")
|
||||
required: true
|
||||
|
||||
outputs:
|
||||
story_file:
|
||||
type: string
|
||||
description: Path to the approved story file
|
||||
format: "docs/stories/epic{epic_number}.story{story_number}.story.md"
|
||||
story_status:
|
||||
type: string
|
||||
description: Final story status
|
||||
expected: "Done"
|
||||
implementation_status:
|
||||
type: string
|
||||
description: Implementation completion status
|
||||
expected: "Complete"
|
||||
|
||||
steps:
|
||||
- step: validate_story_approved
|
||||
agent: po
|
||||
action: approve-story-for-development
|
||||
inputs:
|
||||
- epic_number
|
||||
- story_number
|
||||
condition: "skip_epic_validation_if_same_epic_within_7_days"
|
||||
notes: "REQUIRED: Use Task tool for execution - Validate story readiness, skip epic validation if same epic validated within 7 days"
|
||||
story_status_update: "Approved"
|
||||
|
||||
- step: implement_story
|
||||
agent: dev
|
||||
action: implement-story-development
|
||||
requires: validate_story_approved
|
||||
inputs:
|
||||
- story_file
|
||||
- epic_number
|
||||
- story_number
|
||||
notes: "REQUIRED: Use Task tool for execution - Complete story implementation with validation (includes project quality gates)"
|
||||
story_status_update: "In Progress"
|
||||
|
||||
- step: pre_review_validation
|
||||
agent: dev
|
||||
action: execute-checklist
|
||||
requires: implement_story
|
||||
inputs:
|
||||
- story_file
|
||||
checklist: story-dod-checklist.md
|
||||
notes: "REQUIRED: Use Task tool for execution - Final validation before reviews - ensures project quality gates pass"
|
||||
story_status_update: "Review"
|
||||
checklist_completion_tracking: true
|
||||
|
||||
- step: architect_review
|
||||
agent: architect
|
||||
action: execute-checklist
|
||||
requires: pre_review_validation
|
||||
inputs:
|
||||
- story_file
|
||||
checklist: story-dod-checklist.md
|
||||
notes: "REQUIRED: Use Task tool for execution - Single specialist review for simple changes - validates technical design and implementation"
|
||||
checklist_completion_tracking: true
|
||||
|
||||
- step: implement_fixes
|
||||
agent: dev
|
||||
action: implement-consolidated-fixes
|
||||
requires: architect_review
|
||||
inputs:
|
||||
- story_file
|
||||
- architect_feedback
|
||||
condition: "if_architect_review_has_issues"
|
||||
notes: "REQUIRED: Use Task tool for execution - Implement fixes from architect review if issues identified"
|
||||
|
||||
- step: validate_fixes
|
||||
agent: architect
|
||||
action: validate-consolidated-fixes
|
||||
requires: implement_fixes
|
||||
inputs:
|
||||
- story_file
|
||||
- original_feedback
|
||||
- implemented_fixes
|
||||
condition: "if_fixes_were_implemented"
|
||||
notes: "REQUIRED: Use Task tool for execution - Architect validates fixes using story docs"
|
||||
story_status_update: "Implementation Validated"
|
||||
|
||||
- step: capture_basic_learning
|
||||
agent: architect
|
||||
action: capture-learning-triage
|
||||
requires: [architect_review, validate_fixes]
|
||||
inputs:
|
||||
- story_file
|
||||
- review_feedback
|
||||
- implementation_fixes
|
||||
notes: "REQUIRED: Use Task tool for execution - Extract learnings into structured categories for simple story context"
|
||||
story_status_update: "Learning Extracted"
|
||||
|
||||
- step: commit_and_prepare_pr
|
||||
agent: dev
|
||||
action: commit-and-prepare-pr
|
||||
requires: capture_basic_learning
|
||||
inputs:
|
||||
- story_file
|
||||
- learning_items
|
||||
- implementation_changes
|
||||
notes: "REQUIRED: Use Task tool for execution - Commit implementation changes and prepare comprehensive PR context"
|
||||
story_status_update: "Changes Committed"
|
||||
|
||||
- step: update_epic_progress
|
||||
agent: sm
|
||||
action: update-epic-progress
|
||||
requires: commit_and_prepare_pr
|
||||
inputs:
|
||||
- story_file
|
||||
- epic_number
|
||||
- commit_information
|
||||
- learning_items
|
||||
notes: "REQUIRED: Use Task tool for execution - Update epic progress tracking before PR creation"
|
||||
story_status_update: "Epic Progress Updated"
|
||||
|
||||
- step: create_comprehensive_pr
|
||||
agent: po
|
||||
action: create-comprehensive-pr
|
||||
requires: update_epic_progress
|
||||
inputs:
|
||||
- story_file
|
||||
- commit_information
|
||||
- pr_context
|
||||
- epic_progress_update
|
||||
notes: "REQUIRED: Use Task tool for execution - Create PR with business summary, technical changes, and learning extraction"
|
||||
story_status_update: "Done - Delivered"
|
||||
|
||||
success_criteria:
|
||||
- Story approved for development (epic validation may be skipped if recent)
|
||||
- Story implementation completed with all validations passing
|
||||
- Pre-review validation confirms project quality gates pass
|
||||
- Single architect review validates technical implementation
|
||||
- Any identified issues are resolved and validated
|
||||
- Learning extraction completed with basic triage
|
||||
- Implementation committed with comprehensive context
|
||||
- Epic progress updated with story completion
|
||||
- PR created with business summary and technical details
|
||||
- Story status updated to "Done - Delivered"
|
||||
|
||||
failure_handling:
|
||||
- halt_on_failure: true
|
||||
- Each step must complete successfully before proceeding
|
||||
- Failed steps should be retried after addressing issues
|
||||
|
||||
retry_protocols:
|
||||
story_approval_failure:
|
||||
- Issue: "Story not ready for development or epic validation fails"
|
||||
- Action: "PO addresses story readiness or epic issues"
|
||||
- Retry: "Re-run validate_story_approved after resolution"
|
||||
- Max_retries: 3
|
||||
|
||||
pre_review_failure:
|
||||
- Issue: "Project quality gates fail or DoD checklist incomplete"
|
||||
- Action: "Dev fixes technical issues and quality problems"
|
||||
- Retry: "Re-run pre_review_validation after fixes"
|
||||
- Max_retries: 5
|
||||
|
||||
architect_review_failure:
|
||||
- Issue: "Technical design or implementation issues identified"
|
||||
- Action: "Dev implements architect feedback through implement_fixes step"
|
||||
- Retry: "Proceed to implement_fixes (no retry at review level)"
|
||||
- Notes: "Review outcome flows to fix implementation regardless of pass/fail"
|
||||
|
||||
fixes_validation_failure:
|
||||
- Issue: "Architect finds fixes incomplete or incorrect"
|
||||
- Action: "Dev implements additional fixes based on specific feedback"
|
||||
- Retry: "Re-run implement_fixes → validate_fixes cycle"
|
||||
- Max_retries: 2
|
||||
- Notes: "Simplified retry cycle for single reviewer context"
|
||||
|
||||
learning_triage_failure:
|
||||
- Issue: "Learning extraction incomplete or poorly categorized"
|
||||
- Action: "Architect re-analyzes implementation context and feedback patterns"
|
||||
- Retry: "Re-run capture_basic_learning with improved analysis"
|
||||
- Max_retries: 2
|
||||
- Notes: "Focus on actionable learning items for simple story context"
|
||||
|
||||
commit_preparation_failure:
|
||||
- Issue: "Commit fails or PR context incomplete"
|
||||
- Action: "Dev addresses git issues and completes context preparation"
|
||||
- Retry: "Re-run commit_and_prepare_pr after resolving issues"
|
||||
- Max_retries: 3
|
||||
- Notes: "Ensure all quality gates pass before commit"
|
||||
|
||||
epic_progress_failure:
|
||||
- Issue: "Epic progress update fails or tracking incomplete"
|
||||
- Action: "SM addresses epic file issues and completes progress tracking"
|
||||
- Retry: "Re-run update_epic_progress after resolving tracking issues"
|
||||
- Max_retries: 2
|
||||
- Notes: "Ensure learning integration before PR creation"
|
||||
|
||||
pr_creation_failure:
|
||||
- Issue: "PR creation fails or context incomplete"
|
||||
- Action: "PO addresses GitHub/PR platform issues and completes description"
|
||||
- Retry: "Re-run create_comprehensive_pr after resolving platform issues"
|
||||
- Max_retries: 3
|
||||
- Notes: "Ensure comprehensive business and technical context"
|
||||
|
||||
complexity_validation:
|
||||
simple_story_indicators:
|
||||
- "UI positioning/styling changes"
|
||||
- "Content updates without logic changes"
|
||||
- "Simple configuration changes"
|
||||
- "Documentation updates"
|
||||
- "Small backend changes (single function/endpoint)"
|
||||
- "Bug fixes without architectural impact"
|
||||
- "Parameter tweaks or minor logic adjustments"
|
||||
- "Simple validation or error message updates"
|
||||
|
||||
complex_story_indicators:
|
||||
- "New business workflows or processes"
|
||||
- "Database schema changes"
|
||||
- "Multiple component integration"
|
||||
- "External system integration"
|
||||
- "Authentication/authorization changes"
|
||||
- "Performance optimization requiring architecture changes"
|
||||
- "Cross-system dependencies"
|
||||
|
||||
validation_warning: |
|
||||
⚠️ WARNING: Story complexity may not match selected workflow.
|
||||
Simple workflow selected but story shows complex indicators.
|
||||
Consider using story-implementation workflow for comprehensive validation.
|
||||
|
||||
dependencies:
|
||||
core_bmad_agents:
|
||||
- po (Product Owner)
|
||||
- dev (Developer)
|
||||
- architect (Technical Architect)
|
||||
- sm (Scrum Master)
|
||||
core_bmad_tasks:
|
||||
- execute-checklist
|
||||
- implement-story-development
|
||||
core_bmad_checklists:
|
||||
- story-dod-checklist.md
|
||||
- architect-checklist.md
|
||||
expansion_tasks:
|
||||
- approve-story-for-development
|
||||
- implement-consolidated-fixes
|
||||
- validate-consolidated-fixes
|
||||
- capture-learning-triage
|
||||
- commit-and-prepare-pr
|
||||
- create-comprehensive-pr
|
||||
- update-epic-progress
|
||||
|
||||
handoff_prompts:
|
||||
po_validate_story: "Validate story {epic_number}.{story_number} readiness - may skip epic validation if same epic validated within 7 days"
|
||||
dev_implement: "Story approved. Implement story {epic_number}.{story_number} with validation (project quality gates required)"
|
||||
pre_review: "Implementation complete. Run final validation before architect review - ensure project quality gates pass"
|
||||
architect_review: "Pre-review passed. Conduct technical design and implementation review for simple story"
|
||||
implement_fixes: "Architect review complete. Implement any identified fixes and document changes in story"
|
||||
validate_fixes: "Fixes implemented. Validate fixes using story documentation"
|
||||
capture_learning: "Implementation validated. Extract learnings into structured categories for simple story context"
|
||||
commit_prepare: "Learning extraction complete. Commit implementation changes and prepare comprehensive PR context"
|
||||
update_epic: "Implementation committed. Update epic progress tracking before PR creation"
|
||||
create_pr: "Epic progress updated. Create PR with business summary, technical changes, and learning extraction"
|
||||
workflow_complete: "Story {epic_number}.{story_number} delivered via simple workflow. Epic progress updated with learning integration."
|
||||
Loading…
Reference in New Issue