33 KiB
33 KiB
Implementation Plan: Party Mode Integration with Epic Execute
Option B: Configurable Party Mode
Version: 1.0.0 Status: Draft Author: BMad Method Date: 2026-01-03
Related Documents
| Document | Description |
|---|---|
| README.md | Overview and quick reference |
| 02-context-management.md | Deep dive into context isolation and data transfer |
| 03-file-modifications.md | Detailed file change specifications |
Executive Summary
This plan integrates Party Mode's multi-agent collaboration capabilities into the Epic Execute workflow through configurable CLI flags. Users can enable party phases at specific workflow points to gain diverse agent perspectives during story implementation.
1. New CLI Flags
Shell Script Arguments
Add the following flags to scripts/epic-execute.sh:
# Party Mode Integration Flags
--party-kickoff Enable Story Kickoff Party before each story's dev phase
--party-review Replace single-agent review with multi-agent Party Review
--party-failure Enable Failure Analysis Party when stories fail
--party-retro Enable Post-Epic Retrospective Party after all stories
--party-all Enable all party phases (equivalent to all flags above)
--party-agents LIST Override default agents for party phases (comma-separated)
Usage Examples
# Enable kickoff discussions only
./epic-execute.sh 42 --party-kickoff
# Full party integration
./epic-execute.sh 42 --party-all
# Custom review with specific agents
./epic-execute.sh 42 --party-review --party-agents "Winston,Murat,Amelia"
# Kickoff + Review (most common)
./epic-execute.sh 42 --party-kickoff --party-review
# With existing flags
./epic-execute.sh 42 --party-all --skip-done --verbose
2. Configuration File Updates
File: config/default-config.yaml
Add new party section:
# Party Mode Integration
party:
# Story Kickoff Party - multi-agent discussion before dev phase
kickoff:
enabled: false
agents:
- Winston # Architect - architectural implications
- Amelia # Developer - implementation concerns
- Murat # Test Architect - testing strategy
timeout: 300 # Max seconds for kickoff discussion
output: story # Where to save insights: story | separate | none
# Party Review - replace single-agent review with multi-agent
review:
enabled: false
agents:
- Winston # Architecture alignment
- Murat # Test coverage, security
- Amelia # Code quality, maintainability
timeout: 600 # Max seconds for review party
consensus_required: false # Require all agents to approve
# Failure Analysis Party - triggered on story failure
failure_analysis:
enabled: false
agents:
- Winston # Architectural blockers
- Amelia # Implementation issues
- Bob # Process/requirement issues
auto_trigger: true # Auto-trigger on any failure
# Post-Epic Retrospective Party
retrospective:
enabled: false
agents:
- Mary # Business Analyst - requirements reflection
- Bob # Scrum Master - process reflection
- Winston # Architect - technical reflection
- Amelia # Developer - implementation reflection
generate_handoff: true # Generate rich context handoff document
# Global party settings
settings:
# Communication language for all party discussions
language: "{{communication_language}}"
# Enable TTS for party responses
tts_enabled: false
# Max agents per party phase
max_agents: 4
# Party output format: markdown | yaml | json
output_format: markdown
3. Workflow Integration Points
Enhanced Epic Execute Flow Diagram
┌─────────────────────────────────────────────────────────────────────────┐
│ ENHANCED EPIC EXECUTE FLOW │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ For each story: │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ ┌──────────────────┐ │ │
│ │ │ PARTY: Kickoff │ ← --party-kickoff │ │
│ │ │ (Optional) │ Winston + Amelia + Murat │ │
│ │ │ │ Output: Implementation strategy │ │
│ │ └────────┬─────────┘ Saved to: Story file or separate doc │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ ┌──────────────────┐ │ │
│ │ │ Phase 1: Dev │ Context A (Isolated) │ │
│ │ │ (Standard) │ Includes kickoff insights if generated │ │
│ │ └────────┬─────────┘ │ │
│ │ │ │ │
│ │ ▼ success ▼ failure │ │
│ │ ┌──────────────────┐ ┌──────────────────┐ │ │
│ │ │ Phase 2: Review │ │ PARTY: Failure │ │ │
│ │ │ │ │ Analysis │ ← --party-fail│ │
│ │ │ --party-review? │ │ (Optional) │ │ │
│ │ │ ┌──────────────┐ │ └────────┬─────────┘ │ │
│ │ │ │ YES: Party │ │ │ │ │
│ │ │ │ Review │ │ ▼ │ │
│ │ │ │ Winston + │ │ ┌──────────────────┐ │ │
│ │ │ │ Murat + │ │ │ Retry or Skip │ │ │
│ │ │ │ Amelia │ │ └──────────────────┘ │ │
│ │ │ └──────────────┘ │ │ │
│ │ │ ┌──────────────┐ │ │ │
│ │ │ │ NO: Standard │ │ │ │
│ │ │ │ Single-agent │ │ │ │
│ │ │ │ Review │ │ │ │
│ │ │ └──────────────┘ │ │ │
│ │ └────────┬─────────┘ │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ ┌──────────────────┐ │ │
│ │ │ Phase 3: Commit │ Shell orchestration │ │
│ │ └──────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ After all stories: │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ ┌──────────────────┐ ┌──────────────────┐ │ │
│ │ │ Phase 4: UAT │ │ PARTY: Retro │ ← --party-retro │ │
│ │ │ Generation │ │ (Optional) │ │ │
│ │ │ (Standard) │ │ Mary + Bob + │ │ │
│ │ │ │ │ Winston + Amelia │ │ │
│ │ └──────────────────┘ │ │ │ │
│ │ │ Output: │ │ │
│ │ │ - Retro insights │ │ │
│ │ │ - Context handoff│ │ │
│ │ │ - Patterns doc │ │ │
│ │ └──────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘
4. New Step Files
4.1 Story Kickoff Party
File: steps/step-01b-party-kickoff.md
# Step 1b: Story Kickoff Party
## Purpose
Bring together 2-3 agents for a focused discussion before implementation begins.
Surface architectural concerns, implementation challenges, and testing strategies.
## Agents
Default: Winston (Architect), Amelia (Developer), Murat (Test Architect)
Override: Via --party-agents flag or config
## Input Context
- Story specification (acceptance criteria, technical context)
- Architecture document
- Related stories in the epic
## Discussion Topics
1. **Architectural Implications**
- Winston: How does this fit the overall architecture?
- What integration points exist?
- Are there scalability concerns?
2. **Implementation Approach**
- Amelia: What patterns should we follow?
- Are there existing utilities to leverage?
- What are the tricky parts?
3. **Testing Strategy**
- Murat: What test types are needed?
- What edge cases should we cover?
- Are there test fixtures we need?
## Output Format
```yaml
## Story Kickoff Insights
**Discussion Date**: {{date}}
**Participants**: {{agent_list}}
### Architectural Notes
[Winston's key points]
### Implementation Strategy
[Amelia's recommendations]
### Testing Approach
[Murat's test strategy]
### Identified Risks
- [Risk 1]
- [Risk 2]
### Decisions Made
- [Decision 1 with rationale]
Success Criteria (Analysis Party)
- All agents contributed perspective
- Clear implementation direction established
- Risks identified and documented
- Ready for dev phase to proceed
---
### 4.2 Party Review
**File**: `steps/step-03b-party-review.md`
```markdown
# Step 3b: Party Review (Multi-Agent Code Review)
## Purpose
Replace single-agent code review with multi-agent collaborative review.
Each agent focuses on their domain expertise for thorough coverage.
## Agents
Default: Winston (Architect), Murat (Test Architect), Amelia (Developer)
Override: Via --party-agents flag or config
## Agent Focus Areas
### Winston (Architecture)
- Pattern adherence
- Scalability implications
- API design consistency
- Component boundaries
- Integration concerns
### Murat (Quality)
- Test coverage completeness
- Test quality and meaningfulness
- Security vulnerabilities
- Edge case handling
- CI/CD implications
### Amelia (Implementation)
- Code quality and readability
- Error handling
- Performance considerations
- Documentation quality
- Maintainability
## Review Protocol
1. **Independent Analysis** (per agent)
- Each agent reviews from their perspective
- Categorizes findings by severity (HIGH/MEDIUM/LOW)
2. **Cross-Discussion**
- Agents discuss findings
- Resolve conflicting opinions
- Prioritize issues collectively
3. **Consensus Building**
- Agree on which issues block approval
- Agree on fix priorities
- Generate unified review record
## Output Format
```yaml
## Party Review Record
**Review Date**: {{date}}
**Reviewers**: {{agent_list}}
### Agent Findings
#### 🏗️ Winston (Architecture)
| # | Finding | Severity | Recommendation |
|---|---------|----------|----------------|
#### 🧪 Murat (Quality)
| # | Finding | Severity | Recommendation |
|---|---------|----------|----------------|
#### 💻 Amelia (Implementation)
| # | Finding | Severity | Recommendation |
|---|---------|----------|----------------|
### Cross-Discussion Notes
[Key discussion points and resolutions]
### Consensus Decision
- **Status**: Approved | Approved with Fixes | Rejected
- **Blocking Issues**: [List if any]
- **Required Fixes**: [Prioritized list]
### Fixes Applied
[List of changes made during review]
Issue Fix Policy
Same as standard review:
- HIGH: Always fix
- MEDIUM: Fix if total > 5
- LOW: Document only
Success Criteria (Review Party)
- All agents completed their review focus
- Issues categorized and prioritized
- Consensus reached on approval status
- Required fixes applied and verified
---
### 4.3 Failure Analysis Party
**File**: `steps/step-02b-party-failure.md`
```markdown
# Step 2b: Failure Analysis Party
## Purpose
When a story fails (dev blocked or review failed), convene agents to:
- Diagnose root cause
- Propose remediation
- Identify process improvements
## Trigger Conditions
- Dev phase outputs: `IMPLEMENTATION BLOCKED`
- Review phase outputs: `REVIEW FAILED`
- Test failures after max retries
## Agents
Default: Winston (Architect), Amelia (Developer), Bob (Scrum Master)
Override: Via --party-agents flag
## Discussion Protocol
1. **Failure Context Sharing**
- Present the failure message/log
- Share relevant code context
- Show what was attempted
2. **Root Cause Analysis**
- Winston: Is this an architectural issue?
- Amelia: Is this a technical implementation issue?
- Bob: Is this a requirements/process issue?
3. **Remediation Planning**
- What needs to change?
- Who/what is best positioned to fix it?
- Are there blocking dependencies?
4. **Process Improvement**
- Could this have been caught earlier?
- What should we do differently next time?
## Output Format
```yaml
## Failure Analysis Record
**Analysis Date**: {{date}}
**Story**: {{story_id}}
**Failure Type**: Dev Blocked | Review Failed | Test Failure
**Analysts**: {{agent_list}}
### Failure Summary
[What happened]
### Root Cause Analysis
#### Winston's Assessment
[Architectural perspective]
#### Amelia's Assessment
[Implementation perspective]
#### Bob's Assessment
[Process/requirements perspective]
### Agreed Root Cause
[Consensus diagnosis]
### Remediation Plan
1. [Step 1]
2. [Step 2]
3. [Step 3]
### Blocking Dependencies
- [Dependency 1]
### Process Improvements
- [Improvement for future]
### Recommendation
- **Action**: Retry | Skip | Escalate to Human
- **Rationale**: [Why this action]
Success Criteria (Failure Analysis)
- Root cause identified
- Remediation path clear
- Actionable next step determined
---
### 4.4 Post-Epic Retrospective Party
**File**: `steps/step-05b-party-retro.md`
```markdown
# Step 5b: Post-Epic Retrospective Party
## Purpose
After all stories complete, conduct a multi-agent retrospective to:
- Reflect on what worked and what didn't
- Capture patterns and decisions for future reference
- Generate rich context handoff for epic-chain workflows
## Agents
Default: Mary (Analyst), Bob (Scrum Master), Winston (Architect), Amelia (Developer)
Override: Via --party-agents flag
## Input Context
- All completed story files (with Dev Agent Records and Code Review Records)
- Epic specification
- Execution log/summary
## Discussion Topics
### 1. What Went Well
- Mary: Were requirements clear? Did implementation match intent?
- Bob: How was the sprint flow? Were stories well-sized?
- Winston: Did architecture hold up? Good technical decisions?
- Amelia: Code quality? Patterns established? Developer experience?
### 2. What Could Improve
- Mary: Requirement gaps or ambiguities discovered?
- Bob: Process bottlenecks or inefficiencies?
- Winston: Architectural debt introduced? Future concerns?
- Amelia: Implementation struggles? Missing tooling?
### 3. Patterns Established
- What coding patterns emerged?
- What testing patterns were effective?
- What documentation patterns helped?
### 4. Knowledge Transfer
- What should the next epic's team know?
- What gotchas did we discover?
- What shortcuts are now available?
## Output Format
```yaml
## Epic {{epic_id}} Retrospective
**Date**: {{date}}
**Participants**: {{agent_list}}
### What Went Well
#### Requirements & Business (Mary)
[Points]
#### Process & Flow (Bob)
[Points]
#### Architecture & Design (Winston)
[Points]
#### Implementation & Code (Amelia)
[Points]
### Areas for Improvement
#### Requirements & Business (Mary)
[Points]
#### Process & Flow (Bob)
[Points]
#### Architecture & Design (Winston)
[Points]
#### Implementation & Code (Amelia)
[Points]
### Patterns Established
| Pattern | Description | Files |
|---------|-------------|-------|
| [Name] | [What] | [Where] |
### Key Decisions Log
| Decision | Rationale | Impact |
|----------|-----------|--------|
| [What] | [Why] | [Effect] |
### Gotchas & Lessons Learned
1. [Gotcha]: [What to watch for]
2. [Lesson]: [What we learned]
### Context Handoff for Next Epic
[Rich summary for epic-chain context transfer]
Integration with Epic-Chain
When generate_handoff: true, output is also saved to:
docs/handoffs/epic-{{epic_id}}-handoff.md
This file is automatically loaded by epic-chain for the next epic.
Success Criteria (Retrospective)
- All agents contributed reflections
- Actionable improvements identified
- Patterns documented for reuse
- Context handoff generated (if configured)
---
## 5. Shell Script Modifications
### File: `scripts/epic-execute.sh`
#### 5.1 New Variables
```bash
# Party Mode Flags
PARTY_KICKOFF=false
PARTY_REVIEW=false
PARTY_FAILURE=false
PARTY_RETRO=false
PARTY_AGENTS=""
# Party Mode Step Files
PARTY_KICKOFF_STEP="$BMAD_DIR/workflows/4-implementation/epic-execute/steps/step-01b-party-kickoff.md"
PARTY_REVIEW_STEP="$BMAD_DIR/workflows/4-implementation/epic-execute/steps/step-03b-party-review.md"
PARTY_FAILURE_STEP="$BMAD_DIR/workflows/4-implementation/epic-execute/steps/step-02b-party-failure.md"
PARTY_RETRO_STEP="$BMAD_DIR/workflows/4-implementation/epic-execute/steps/step-05b-party-retro.md"
5.2 Argument Parsing Additions
while [[ $# -gt 0 ]]; do
case $1 in
# ... existing flags ...
--party-kickoff)
PARTY_KICKOFF=true
shift
;;
--party-review)
PARTY_REVIEW=true
shift
;;
--party-failure)
PARTY_FAILURE=true
shift
;;
--party-retro)
PARTY_RETRO=true
shift
;;
--party-all)
PARTY_KICKOFF=true
PARTY_REVIEW=true
PARTY_FAILURE=true
PARTY_RETRO=true
shift
;;
--party-agents)
PARTY_AGENTS="$2"
shift 2
;;
# ... rest of cases ...
esac
done
5.3 New Functions
# =============================================================================
# Party Mode Functions
# =============================================================================
execute_party_kickoff() {
local story_file="$1"
local story_id=$(basename "$story_file" .md)
log ">>> PARTY KICKOFF: $story_id"
local story_contents=$(cat "$story_file")
local agents="${PARTY_AGENTS:-Winston,Amelia,Murat}"
local kickoff_prompt="You are orchestrating a Story Kickoff Party for BMAD.
## Participating Agents
$agents
## Story to Discuss
<story>
$story_contents
</story>
## Your Task
Facilitate a focused discussion between the agents about this story.
Each agent should contribute from their expertise:
- Winston (Architect): Architectural implications, integration points
- Amelia (Developer): Implementation approach, patterns to follow
- Murat (Test Architect): Testing strategy, edge cases
## Output
Generate a Story Kickoff Insights section to append to the story file.
Format as markdown with clear sections for each agent's input.
When complete, output: KICKOFF COMPLETE: $story_id"
if [ "$DRY_RUN" = true ]; then
echo "[DRY RUN] Would execute party kickoff for $story_id"
return 0
fi
local result
result=$(claude --dangerously-skip-permissions -p "$kickoff_prompt" 2>&1) || true
echo "$result" >> "$LOG_FILE"
if echo "$result" | grep -q "KICKOFF COMPLETE"; then
log_success "Party kickoff complete: $story_id"
return 0
else
log_warn "Party kickoff may not have completed cleanly"
return 0 # Non-blocking - continue to dev phase
fi
}
execute_party_review() {
local story_file="$1"
local story_id=$(basename "$story_file" .md)
log ">>> PARTY REVIEW: $story_id (multi-agent)"
local story_contents=$(cat "$story_file")
local agents="${PARTY_AGENTS:-Winston,Murat,Amelia}"
local review_prompt="You are orchestrating a Party Code Review for BMAD.
## Participating Agents
$agents
## Story Being Reviewed
<story>
$story_contents
</story>
## Review Focus Areas
- Winston (Architecture): Pattern adherence, scalability, API design
- Murat (Quality): Test coverage, security, edge cases
- Amelia (Implementation): Code quality, readability, maintainability
## Your Task
1. Run: git diff --staged
2. Each agent reviews from their perspective
3. Categorize issues by severity (HIGH/MEDIUM/LOW)
4. Facilitate cross-discussion to reach consensus
5. Apply fix policy: HIGH always, MEDIUM if >5 total, LOW document only
6. Generate Party Review Record
## Completion
If PASSED: Update story Status to Done, output: PARTY REVIEW PASSED: $story_id
If FAILED: Update story Status to Blocked, output: PARTY REVIEW FAILED: $story_id - [reason]"
if [ "$DRY_RUN" = true ]; then
echo "[DRY RUN] Would execute party review for $story_id"
return 0
fi
local result
result=$(claude --dangerously-skip-permissions -p "$review_prompt" 2>&1) || true
echo "$result" >> "$LOG_FILE"
if echo "$result" | grep -q "PARTY REVIEW PASSED"; then
log_success "Party review passed: $story_id"
return 0
elif echo "$result" | grep -q "PARTY REVIEW FAILED"; then
log_error "Party review failed: $story_id"
return 1
else
log_warn "Party review did not complete cleanly"
return 1
fi
}
execute_party_failure_analysis() {
local story_file="$1"
local story_id=$(basename "$story_file" .md)
local failure_type="$2" # "dev" or "review"
log ">>> PARTY FAILURE ANALYSIS: $story_id"
local story_contents=$(cat "$story_file")
local agents="${PARTY_AGENTS:-Winston,Amelia,Bob}"
local failure_prompt="You are orchestrating a Failure Analysis Party for BMAD.
## Participating Agents
$agents
## Failed Story
<story>
$story_contents
</story>
## Failure Type
$failure_type phase failed
## Your Task
1. Present failure context to agents
2. Facilitate root cause analysis:
- Winston: Architectural issues?
- Amelia: Implementation issues?
- Bob: Requirements/process issues?
3. Build remediation plan
4. Recommend action: Retry | Skip | Escalate
## Output
Generate Failure Analysis Record.
Output: ANALYSIS COMPLETE: $story_id - [Retry|Skip|Escalate]"
if [ "$DRY_RUN" = true ]; then
echo "[DRY RUN] Would execute failure analysis for $story_id"
return 0
fi
local result
result=$(claude --dangerously-skip-permissions -p "$failure_prompt" 2>&1) || true
echo "$result" >> "$LOG_FILE"
log_success "Failure analysis complete: $story_id"
}
execute_party_retro() {
log ">>> PARTY RETROSPECTIVE: Epic $EPIC_ID"
local epic_contents=$(cat "$EPIC_FILE")
local agents="${PARTY_AGENTS:-Mary,Bob,Winston,Amelia}"
local all_stories=""
for story_file in "${STORIES[@]}"; do
local story_id=$(basename "$story_file" .md)
all_stories+="
<story id=\"$story_id\">
$(cat "$story_file")
</story>
"
done
local retro_prompt="You are orchestrating a Post-Epic Retrospective Party for BMAD.
## Participating Agents
$agents
## Epic Completed
<epic>
$epic_contents
</epic>
## Completed Stories
$all_stories
## Your Task
Facilitate retrospective discussion:
1. What Went Well (each agent's perspective)
2. Areas for Improvement (each agent's perspective)
3. Patterns Established (document for reuse)
4. Key Decisions Log
5. Gotchas & Lessons Learned
6. Context Handoff for Next Epic
## Output
Generate retrospective document at: docs/sprints/epic-${EPIC_ID}-retro.md
Generate handoff document at: docs/handoffs/epic-${EPIC_ID}-handoff.md
When complete, output: RETRO COMPLETE: Epic $EPIC_ID"
if [ "$DRY_RUN" = true ]; then
echo "[DRY RUN] Would execute party retrospective"
return 0
fi
local result
result=$(claude --dangerously-skip-permissions -p "$retro_prompt" 2>&1) || true
echo "$result" >> "$LOG_FILE"
if echo "$result" | grep -q "RETRO COMPLETE"; then
log_success "Party retrospective complete"
else
log_warn "Retrospective may not have completed cleanly"
fi
}
5.4 Main Loop Modifications
# =============================================================================
# Main Execution Loop (Modified)
# =============================================================================
for story_file in "${STORIES[@]}"; do
story_id=$(basename "$story_file" .md)
# ... existing skip logic ...
echo ""
log "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
log "Story: $story_id"
log "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
# PARTY KICKOFF (Optional - Context 0)
if [ "$PARTY_KICKOFF" = true ]; then
execute_party_kickoff "$story_file"
fi
# DEV PHASE (Context 1)
if ! execute_dev_phase "$story_file"; then
log_error "Dev phase failed for $story_id"
# PARTY FAILURE ANALYSIS (Optional)
if [ "$PARTY_FAILURE" = true ]; then
execute_party_failure_analysis "$story_file" "dev"
fi
((FAILED++))
continue
fi
# REVIEW PHASE (Context 2 - Fresh)
if [ "$SKIP_REVIEW" = false ]; then
if [ "$PARTY_REVIEW" = true ]; then
# Multi-agent party review
if ! execute_party_review "$story_file"; then
log_error "Party review failed for $story_id"
if [ "$PARTY_FAILURE" = true ]; then
execute_party_failure_analysis "$story_file" "review"
fi
((FAILED++))
continue
fi
else
# Standard single-agent review
if ! execute_review_phase "$story_file"; then
log_error "Review phase failed for $story_id"
((FAILED++))
continue
fi
fi
fi
# COMMIT
commit_story "$story_id"
((COMPLETED++))
log_success "Story complete: $story_id ($COMPLETED/${#STORIES[@]})"
done
# =============================================================================
# Post-Epic Activities
# =============================================================================
# UAT Generation (Standard)
generate_uat
# PARTY RETROSPECTIVE (Optional)
if [ "$PARTY_RETRO" = true ]; then
execute_party_retro
fi
6. File Structure After Implementation
src/modules/bmm/workflows/4-implementation/epic-execute/
├── workflow.md # Updated with party mode references
├── config/
│ └── default-config.yaml # Updated with party section
├── steps/
│ ├── step-01-init.md # Existing
│ ├── step-01b-party-kickoff.md # NEW: Story Kickoff Party
│ ├── step-02-dev-story.md # Existing
│ ├── step-02b-party-failure.md # NEW: Failure Analysis Party
│ ├── step-03-code-review.md # Existing (used when party-review disabled)
│ ├── step-03b-party-review.md # NEW: Multi-Agent Party Review
│ ├── step-04-generate-uat.md # Existing
│ ├── step-05-summary.md # Existing
│ └── step-05b-party-retro.md # NEW: Post-Epic Retrospective Party
└── prompts/
├── kickoff-party.md # Full prompt template
├── review-party.md # Full prompt template
├── failure-party.md # Full prompt template
└── retro-party.md # Full prompt template
scripts/
└── epic-execute.sh # Updated with party functions
7. Implementation Phases
Phase 1: Foundation (Priority: High)
- Add CLI flag parsing to
epic-execute.sh - Add party section to
default-config.yaml - Create
step-01b-party-kickoff.md - Implement
execute_party_kickoff()function - Wire kickoff into main loop
Phase 2: Core Integration (Priority: High)
- Create
step-03b-party-review.md - Implement
execute_party_review()function - Add conditional logic for party vs standard review
- Test party review with sample epic
Phase 3: Error Handling (Priority: Medium)
- Create
step-02b-party-failure.md - Implement
execute_party_failure_analysis()function - Wire failure analysis into dev/review failure paths
Phase 4: Retrospective & Handoff (Priority: Medium)
- Create
step-05b-party-retro.md - Implement
execute_party_retro()function - Integrate with epic-chain context handoff system
- Create handoff document templates
Phase 5: Polish (Priority: Low)
- Add
--party-agentsoverride support - Add TTS integration for party phases
- Create comprehensive documentation
- Add metrics tracking for party phases
8. Testing Strategy
Unit Tests
- Flag parsing works correctly
- Config loading includes party section
- Agent list parsing handles various formats
Integration Tests
# Test kickoff only
./epic-execute.sh test-epic --party-kickoff --dry-run
# Test full party mode
./epic-execute.sh test-epic --party-all --dry-run
# Test custom agents
./epic-execute.sh test-epic --party-review --party-agents "Winston,Murat" --dry-run
Manual Validation
- Run with real epic to validate agent interactions
- Verify output document quality
- Confirm context isolation still works with party phases
9. Rollback Plan
Party mode is additive and opt-in:
- All flags default to
false - Standard workflow unchanged when flags not used
- Can disable individual party phases independently
- No changes to existing step files
10. Success Metrics
| Metric | Target | Measurement |
|---|---|---|
| Issue detection rate | +25% | Compare issues found in party review vs standard |
| Architectural issues caught early | +40% | Track issues surfaced in kickoff |
| Context handoff quality | Subjective | Developer satisfaction with handoff docs |
| Failure remediation time | -30% | Time from failure to successful retry |
11. Future Enhancements
- Complexity-Based Auto-Trigger: Automatically enable party phases for high-complexity stories
- Agent Recommendation Engine: Suggest optimal agents based on story content
- Party Analytics: Track which agent combinations produce best results
- Async Party Mode: Run party phases in background while other work continues
- Human-in-Party: Allow human to join party discussions at key decision points