---
name: bmad-retrospective
description: 'Post-epic review to extract lessons and assess success. Use when the user says "run a retrospective" or "lets retro the epic [epic]"'
---

## 🧠 Memtrace Context (Self-Contained)

The retrospective workflow has access to Memtrace structural analysis tools for objective technical debt assessment.

### Tools Referenced

| Tool | Purpose | Key Parameters |
|------|---------|----------------|
| `list_indexed_repositories` | Index freshness check | None — call before every query block |
| `get_evolution` | Discover all symbols/files changed in sprint timeframe | `from`, `to` (ISO-8601), `mode="compound"` |
| `get_impact` | Compute blast radius for key changes | `target` (symbol name), `direction="both"`, `depth=3` |
| `find_most_complex_functions` | Detect complexity hotspots | `top_n=15`, `kinds=["Function","Method"]` |
| `find_bridge_symbols` | Identify chokepoints that changed | `limit=15` |
| `find_central_symbols` | Identify load-bearing code that changed | `limit=20` |
| `list_communities` | Detect cross-module coupling | `min_size=3` |
| `find_dead_code` | Surface orphaned symbols from refactors | `include_tests=false`, `limit=50` |

### Usage Rules

1. **Index Freshness First**: Always call `list_indexed_repositories` before any graph query. If the repo is not indexed or last_indexed is stale, skip ALL graph queries.
2. **Sequential Only**: ALL Memtrace queries MUST use `for...of` with `await`. `Promise.all` is FORBIDDEN.
3. **Token Budget**: Cap results at 200 symbols per query batch. Prefer summarized/compound output modes.
4. **Advisory Only**: Structural data ENRICHES the retrospective — it does not dictate outcomes. The team and {user_name} decide priorities.
5. **Graceful Degradation**: If ANY Memtrace tool fails (timeout, not indexed, server down), skip graph queries and continue with heuristic analysis. Log the skip reason.
6. **Timeout Handling**: Queries time out at 10000ms. On timeout, skip the query and continue.
7. **No Process Management**: Never invoke server restart commands in the retrospective workflow.

### Data Flow

```
Step 2: get_evolution → get_impact → find_most_complex_functions
        → find_bridge_symbols → find_central_symbols → list_communities
        → find_dead_code → {{memtrace_structural_insights}}
                                                        ↓
Step 8: {{memtrace_structural_insights}} → Present evidence → Recommend action items
```

### Fallback Path

When Memtrace is unavailable, the retrospective continues with:
- Story file reading and dev note extraction (existing logic)
- Team discussion-based pattern detection
- Heuristic technical debt identification
- All existing conversation flows preserved

# Retrospective Workflow

**Goal:** Post-epic review to extract lessons and assess success.

**Your Role:** Developer facilitating retrospective.
- No time estimates — NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed.
- Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}
- Generate all documents in {document_output_language}
- Document output: Retrospective analysis. Concise insights, lessons learned, action items. User skill level ({user_skill_level}) affects conversation style ONLY, not retrospective content.
- Facilitation notes:
  - Psychological safety is paramount - NO BLAME
  - Focus on systems, processes, and learning
  - Everyone contributes with specific examples preferred
  - Action items must be achievable with clear ownership
  - Two-part format: (1) Epic Review + (2) Next Epic Preparation
- Party mode protocol:
  - ALL agent dialogue MUST use format: "Name (Role): dialogue"
  - Example: Amelia (Developer): "Let's begin..."
  - Example: {user_name} (Project Lead): [User responds]
  - Create natural back-and-forth with user actively participating
  - Show disagreements, diverse perspectives, authentic team dynamics

## Conventions

- Bare paths resolve from the skill root.
- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
- `{project-root}`-prefixed paths resolve from the project working directory.
- `{skill-name}` resolves to the skill directory's basename.

## On Activation

### Step 1: Resolve the Workflow Block

Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`

**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:

1. `{skill-root}/customize.toml` — defaults
2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides

Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.

### Step 2: Execute Prepend Steps

Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.

### Step 3: Load Persistent Facts

Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.

### Step 4: Load Config

Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:

- `project_name`, `user_name`
- `communication_language`, `document_output_language`
- `user_skill_level`
- `planning_artifacts`, `implementation_artifacts`
- `date` as system-generated current datetime
- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`

### Step 5: Greet the User

Greet `{user_name}`, speaking in `{communication_language}`.

### Step 6: Execute Append Steps

Execute each entry in `{workflow.activation_steps_append}` in order.

Activation is complete. Begin the workflow below.

## Paths

- `sprint_status_file` = `{implementation_artifacts}/sprint-status.yaml`

## Input Files

| Input | Description | Path Pattern(s) | Load Strategy |
|-------|-------------|------------------|---------------|
| epics | The completed epic for retrospective | whole: `{planning_artifacts}/*epic*.md`, sharded_index: `{planning_artifacts}/*epic*/index.md`, sharded_single: `{planning_artifacts}/*epic*/epic-{{epic_num}}.md` | SELECTIVE_LOAD |
| previous_retrospective | Previous epic's retrospective (optional) | `{implementation_artifacts}/**/epic-{{prev_epic_num}}-retro-*.md` | SELECTIVE_LOAD |
| architecture | System architecture for context | whole: `{planning_artifacts}/*architecture*.md`, sharded: `{planning_artifacts}/*architecture*/*.md` | FULL_LOAD |
| prd | Product requirements for context | whole: `{planning_artifacts}/*prd*.md`, sharded: `{planning_artifacts}/*prd*/*.md` | FULL_LOAD |
| document_project | Brownfield project documentation (optional) | sharded: `{planning_artifacts}/*.md` | INDEX_GUIDED |

## Required Inputs

- `agent_roster` = resolved via `python3 {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key agents` (merges four layers in order: `_bmad/config.toml`, `_bmad/config.user.toml`, `_bmad/custom/config.toml`, `_bmad/custom/config.user.toml`)

## Execution

<workflow>

<step n="1" goal="Epic Discovery - Find Completed Epic with Priority Logic">

<action>Explain to {user_name} the epic discovery process using natural dialogue</action>

<output>
Amelia (Developer): "Welcome to the retrospective, {user_name}. Let me help you identify which epic we just completed. I'll check sprint-status first, but you're the ultimate authority on what we're reviewing today."
</output>

<action>PRIORITY 1: Check {sprint_status_file} first</action>

<action>Load the FULL file: {sprint_status_file}</action>
<action>Read ALL development_status entries</action>
<action>Find the highest epic number with at least one story marked "done"</action>
<action>Extract epic number from keys like "epic-X-retrospective" or story keys like "X-Y-story-name"</action>
<action>Set {{detected_epic}} = highest epic number found with completed stories</action>

<check if="{{detected_epic}} found">
  <action>Present finding to user with context</action>

  <output>
Amelia (Developer): "Based on {sprint_status_file}, it looks like Epic {{detected_epic}} was recently completed. Is that the epic you want to review today, {user_name}?"
  </output>

<action>WAIT for {user_name} to confirm or correct</action>

  <check if="{user_name} confirms">
    <action>Set {{epic_number}} = {{detected_epic}}</action>
  </check>

  <check if="{user_name} provides different epic number">
    <action>Set {{epic_number}} = user-provided number</action>
    <output>
Amelia (Developer): "Got it, we're reviewing Epic {{epic_number}}. Let me gather that information."
    </output>
  </check>
</check>

<check if="{{detected_epic}} NOT found in sprint-status">
  <action>PRIORITY 2: Ask user directly</action>

  <output>
Amelia (Developer): "I'm having trouble detecting the completed epic from {sprint_status_file}. {user_name}, which epic number did you just complete?"
  </output>

<action>WAIT for {user_name} to provide epic number</action>
<action>Set {{epic_number}} = user-provided number</action>
</check>

<check if="{{epic_number}} still not determined">
  <action>PRIORITY 3: Fallback to stories folder</action>

<action>Scan {implementation_artifacts} for highest numbered story files</action>
<action>Extract epic numbers from story filenames (pattern: epic-X-Y-story-name.md)</action>
<action>Set {{detected_epic}} = highest epic number found</action>

  <output>
Amelia (Developer): "I found stories for Epic {{detected_epic}} in the stories folder. Is that the epic we're reviewing, {user_name}?"
  </output>

<action>WAIT for {user_name} to confirm or correct</action>
<action>Set {{epic_number}} = confirmed number</action>
</check>

<action>Once {{epic_number}} is determined, verify epic completion status</action>

<action>Find all stories for epic {{epic_number}} in {sprint_status_file}:

- Look for keys starting with "{{epic_number}}-" (e.g., "1-1-", "1-2-", etc.)
- Exclude epic key itself ("epic-{{epic_number}}")
- Exclude retrospective key ("epic-{{epic_number}}-retrospective")
  </action>

<action>Count total stories found for this epic</action>
<action>Count stories with status = "done"</action>
<action>Collect list of pending story keys (status != "done")</action>
<action>Determine if complete: true if all stories are done, false otherwise</action>

<check if="epic is not complete">
  <output>
Alice (Product Owner): "Wait, Amelia - I'm seeing that Epic {{epic_number}} isn't actually complete yet."

Amelia (Developer): "Let me check... you're right, Alice."

**Epic Status:**

- Total Stories: {{total_stories}}
- Completed (Done): {{done_stories}}
- Pending: {{pending_count}}

**Pending Stories:**
{{pending_story_list}}

Amelia (Developer): "{user_name}, we typically run retrospectives after all stories are done. What would you like to do?"

**Options:**

1. Complete remaining stories before running retrospective (recommended)
2. Continue with partial retrospective (not ideal, but possible)
3. Run sprint-planning to refresh story tracking
   </output>

<ask if="{{non_interactive}} == false">Continue with incomplete epic? (yes/no)</ask>

  <check if="user says no">
    <output>
Amelia (Developer): "Smart call, {user_name}. Let's finish those stories first and then have a proper retrospective."
    </output>
    <action>HALT</action>
  </check>

<action if="user says yes">Set {{partial_retrospective}} = true</action>
<output>
Charlie (Senior Dev): "Just so everyone knows, this partial retro might miss some important lessons from those pending stories."

Amelia (Developer): "Good point, Charlie. {user_name}, we'll document what we can now, but we may want to revisit after everything's done."
</output>
</check>

<check if="epic is complete">
  <output>
Alice (Product Owner): "Excellent! All {{done_stories}} stories are marked done."

Amelia (Developer): "Perfect. Epic {{epic_number}} is complete and ready for retrospective, {user_name}."
</output>
</check>

</step>

<step n="0.5" goal="Discover and load project documents">
  <action>Load input files according to the Input Files table above. For SELECTIVE_LOAD inputs, load only the epic matching {{epic_number}}. For FULL_LOAD inputs, load the complete document. For INDEX_GUIDED inputs, check the index first and load relevant sections. After discovery, these content variables are available: {epics_content} (selective load for this epic), {architecture_content}, {prd_content}, {document_project_content}</action>
  <note>After discovery, these content variables are available: {epics_content} (selective load for this epic), {architecture_content}, {prd_content}, {document_project_content}</note>
</step>

<step n="2" goal="Deep Story Analysis - Extract Lessons from Implementation">

<output>
Amelia (Developer): "Before we start the team discussion, let me review all the story records to surface key themes. This'll help us have a richer conversation."

Charlie (Senior Dev): "Good idea - those dev notes always have gold in them."
</output>

<action>For each story in epic {{epic_number}}, read the complete story file from {implementation_artifacts}/{{epic_number}}-{{story_num}}-*.md</action>

<action>Extract and analyze from each story:</action>

**Dev Notes and Struggles:**

- Look for sections like "## Dev Notes", "## Implementation Notes", "## Challenges", "## Development Log"
- Identify where developers struggled or made mistakes
- Note unexpected complexity or gotchas discovered
- Record technical decisions that didn't work out as planned
- Track where estimates were way off (too high or too low)

**Review Feedback Patterns:**

- Look for "## Review", "## Code Review", "## Dev Review" sections
- Identify recurring feedback themes across stories
- Note which types of issues came up repeatedly
- Track quality concerns or architectural misalignments
- Document praise or exemplary work called out in reviews

**Lessons Learned:**

- Look for "## Lessons Learned", "## Retrospective Notes", "## Takeaways" sections within stories
- Extract explicit lessons documented during development
- Identify "aha moments" or breakthroughs
- Note what would be done differently
- Track successful experiments or approaches

**Technical Debt Incurred:**

- Look for "## Technical Debt", "## TODO", "## Known Issues", "## Future Work" sections
- Document shortcuts taken and why
- Track debt items that affect next epic
- Note severity and priority of debt items

**Testing and Quality Insights:**

- Look for "## Testing", "## QA Notes", "## Test Results" sections
- Note testing challenges or surprises
- Track bug patterns or regression issues
- Document test coverage gaps

  <action>Check Memtrace availability for structural evolution analysis:
  - Use `list_indexed_repositories` to confirm the project repo is indexed
  - If indexed: check the `last_indexed_at` timestamp — if the last index is more than 24 hours older than the current time, treat it as stale
  - If indexed AND fresh: set `memtrace_available = true` and proceed with graph-based discovery
  - If NOT indexed or stale: set `memtrace_available = false` and skip to traditional pattern synthesis
</action>

<check if="memtrace_available == true">
  <output>
Amelia (Developer): "While I have the story records loaded, let me also check what the codebase graph reveals about this sprint's structural impact..."

Charlie (Senior Dev): "The graph? You mean Memtrace can show us what actually changed structurally?"

Amelia (Developer): "Exactly. The story files tell us what developers REPORTED. The graph tells us what actually HAPPENED to the code."
  </output>

  <action>Graph-Based Structural Evolution Analysis:

  **A) Discover What Changed During the Sprint:**
  - Determine the sprint timeframe: use the earliest story's creation date as `from`, and the latest story's completion date as `to`
  - Call `get_evolution` (repo_id={{repo_id}}, from={{sprint_start}}, to={{sprint_end}}, mode="compound")
  - This returns: top-N changed files, top-N touched symbols, total change volume
  - The compound mode gives a rolled-up view without per-episode detail — ideal for retro-level analysis
  - Store as `{{evolution_summary}}` with: total_files_changed, total_symbols_touched, top_changed_files (with change counts), top_touched_symbols

  **B) Complexity Hotspot Detection in Modified Modules:**
  - Extract the directory paths of the top-N most-changed files from step A
  - For each modified directory, call `find_most_complex_functions` (repo_id={{repo_id}}, top_n=15, kinds=["Function","Method"])
  - Filter to functions whose file_path falls within the modified directories
  - Cross-reference with `get_evolution` data: if a function was both MODIFIED during the sprint AND has high complexity (>10), flag it as a "complexity hotspot"
  - Store as `{{complexity_hotspots}}`: function name, file_path, complexity_score, risk_level, was_modified_during_sprint (bool)
  - Process queries SEQUENTIALLY — one directory at a time with `await`

  **C) Architectural Stress Analysis:**
  - Call `find_bridge_symbols` (repo_id={{repo_id}}, limit=15) to get the current top chokepoints
  - Call `find_central_symbols` (repo_id={{repo_id}}, limit=20) to get the current top load-bearing symbols
  - Filter to symbols whose file_path falls within the modified directories from step A
  - If ANY bridge or central symbols were modified during the sprint, flag as "ARCHITECTURAL STRESS"
  - Bridge symbols modified → chokepoint risk (changes cascade unexpectedly)
  - Central symbols modified → load-bearing code risk (changes have maximum blast radius)
  - Store as `{{architectural_stress}}`: stressed_bridge_symbols[], stressed_central_symbols[]

  **D) Cross-Module Coupling Detection:**
  - Call `list_communities` (repo_id={{repo_id}}, min_size=3) to get current community clusters
  - Cross-reference modified symbols (from step A) with community membership
  - Count: how many DIFFERENT communities were touched by the sprint's changes
  - If symbols from 3+ communities were modified, flag as "HIGH CROSS-MODULE COUPLING"
  - If modifications within a community introduced new cross-community edges, flag as "COUPLING INCREASE"
  - Store as `{{coupling_analysis}}`: communities_touched (count, names), cross_community_edge_count

  **E) Orphan Risk Assessment:**
  - Call `find_dead_code` (repo_id={{repo_id}}, include_tests=false, limit=50)
  - Filter to dead code symbols whose file_path falls within the modified directories
  - These are symbols that may have been orphaned by sprint refactors
  - Flag as "ORPHAN RISK" — symbols to investigate for potential removal
  - Store as `{{orphan_risk}}`: orphaned_symbols[] with file_path, kind

  </action>

  <action>Validate all queries completed successfully (no timeout errors)</action>
  <action>Process ALL queries STRICTLY SEQUENTIALLY using `for...of` with `await` — NEVER Promise.all</action>
  <action>Cap each query result at 200 symbols to stay within token budget</action>

  <action>Synthesize Structural Insights:
    - Combine evolution_summary + complexity_hotspots + architectural_stress + coupling_analysis + orphan_risk
    - Produce a structured `{{memtrace_structural_insights}}` object:
      {
        "available": true,
        "timeframe": {from, to},
        "change_volume": {files_changed, symbols_touched},
        "complexity_hotspots": [{name, file_path, complexity, risk_level}],
        "architectural_stress": {bridge_symbols_modified, central_symbols_modified},
        "coupling": {communities_touched, cross_community_edges},
        "orphan_risk": [{name, file_path, kind}],
        "summary": "Human-readable summary of structural impact"
      }
    - Store for use in Step 8 (Synthesize Action Items)
  </action>

  <output>
Amelia (Developer): "The graph data adds some interesting dimensions to what the story files told us."

Charlie (Senior Dev): "Like what?"

Amelia (Developer): "{{summary_from_structural_insights}}"

{user_name} (Project Lead): [Can react to structural findings]

Amelia (Developer): "Let me now combine this with the story file patterns I extracted..."
  </output>
</check>

<check if="memtrace_available == false">
  <output>
Amelia (Developer): "I tried to check the codebase graph for structural data, but Memtrace isn't available right now."

Charlie (Senior Dev): "No worries — we still have all the story records and dev notes."

Amelia (Developer): "Right. Let me continue with the story file pattern analysis."
  </output>
  <action>Set `memtrace_available = false` for use in Step 8</action>
</check>

<action>Synthesize patterns across all stories:</action>

**Common Struggles:**

- Identify issues that appeared in 2+ stories (e.g., "3 out of 5 stories had API authentication issues")
- Note areas where team consistently struggled
- Track where complexity was underestimated

**Recurring Review Feedback:**

- Identify feedback themes (e.g., "Error handling was flagged in every review")
- Note quality patterns (positive and negative)
- Track areas where team improved over the course of epic

**Breakthrough Moments:**

- Document key discoveries (e.g., "Story 3 discovered the caching pattern we used for rest of epic")
- Note when team velocity improved dramatically
- Track innovative solutions worth repeating

**Velocity Patterns:**

- Calculate average completion time per story
- Note velocity trends (e.g., "First 2 stories took 3x longer than estimated")
- Identify which types of stories went faster/slower

**Team Collaboration Highlights:**

- Note moments of excellent collaboration mentioned in stories
- Track where pair programming or mob programming was effective
- Document effective problem-solving sessions

<action>Store this synthesis - these patterns will drive the retrospective discussion</action>

<output>
Amelia (Developer): "Okay, I've reviewed all {{total_stories}} story records. I found some really interesting patterns we should discuss."

Dana (QA Engineer): "I'm curious what you found, Amelia. I noticed some things in my testing too."

Amelia (Developer): "We'll get to all of it. But first, let me load the previous epic's retro to see if we learned from last time."
</output>

</step>

<step n="3" goal="Load and Integrate Previous Epic Retrospective">

<action>Calculate previous epic number: {{prev_epic_num}} = {{epic_number}} - 1</action>

<check if="{{prev_epic_num}} >= 1">
  <action>Search for previous retrospectives using pattern: {implementation_artifacts}/epic-{{prev_epic_num}}-retro-*.md</action>

  <check if="previous retrospectives found">
    <output>
Amelia (Developer): "I found our retrospectives from Epic {{prev_epic_num}}. Let me see what we committed to back then..."
    </output>

    <action>Read the previous retrospectives</action>

    <action>Extract key elements:</action>
    - **Action items committed**: What did the team agree to improve?
    - **Lessons learned**: What insights were captured?
    - **Process improvements**: What changes were agreed upon?
    - **Technical debt flagged**: What debt was documented?
    - **Team agreements**: What commitments were made?
    - **Preparation tasks**: What was needed for this epic?

    <action>Cross-reference with current epic execution:</action>

    **Action Item Follow-Through:**
    - For each action item from Epic {{prev_epic_num}} retro, check if it was completed
    - Look for evidence in current epic's story records
    - Mark each action item: ✅ Completed, ⏳ In Progress, ❌ Not Addressed

    **Lessons Applied:**
    - For each lesson from Epic {{prev_epic_num}}, check if team applied it in Epic {{epic_number}}
    - Look for evidence in dev notes, review feedback, or outcomes
    - Document successes and missed opportunities

    **Process Improvements Effectiveness:**
    - For each process change agreed to in Epic {{prev_epic_num}}, assess if it helped
    - Did the change improve velocity, quality, or team satisfaction?
    - Should we keep, modify, or abandon the change?

    **Technical Debt Status:**
    - For each debt item from Epic {{prev_epic_num}}, check if it was addressed
    - Did unaddressed debt cause problems in Epic {{epic_number}}?
    - Did the debt grow or shrink?

    <action>Prepare "continuity insights" for the retrospective discussion</action>

    <action>Identify wins where previous lessons were applied successfully:</action>
    - Document specific examples of applied learnings
    - Note positive impact on Epic {{epic_number}} outcomes
    - Celebrate team growth and improvement

    <action>Identify missed opportunities where previous lessons were ignored:</action>
    - Document where team repeated previous mistakes
    - Note impact of not applying lessons (without blame)
    - Explore barriers that prevented application

    <output>

Amelia (Developer): "Interesting... in Epic {{prev_epic_num}}'s retro, we committed to {{action_count}} action items."

Alice (Product Owner): "How'd we do on those, Amelia?"

Amelia (Developer): "We completed {{completed_count}}, made progress on {{in_progress_count}}, but didn't address {{not_addressed_count}}."

Charlie (Senior Dev): _looking concerned_ "Which ones didn't we address?"

Amelia (Developer): "We'll discuss that in the retro. Some of them might explain challenges we had this epic."

Elena (Junior Dev): "That's... actually pretty insightful."

Amelia (Developer): "That's why we track this stuff. Pattern recognition helps us improve."
</output>

  </check>

  <check if="no previous retro found">
    <output>
Amelia (Developer): "I don't see a retrospective for Epic {{prev_epic_num}}. Either we skipped it, or this is your first retro."

Alice (Product Owner): "Probably our first one. Good time to start the habit!"
</output>
<action>Set {{first_retrospective}} = true</action>
</check>
</check>

<check if="{{prev_epic_num}} < 1">
  <output>
Amelia (Developer): "This is Epic 1, so naturally there's no previous retro to reference. We're starting fresh!"

Charlie (Senior Dev): "First epic, first retro. Let's make it count."
</output>
<action>Set {{first_retrospective}} = true</action>
</check>

</step>

<step n="4" goal="Preview Next Epic with Change Detection">

<action>Calculate next epic number: {{next_epic_num}} = {{epic_number}} + 1</action>

<output>
Amelia (Developer): "Before we dive into the discussion, let me take a quick look at Epic {{next_epic_num}} to understand what's coming."

Alice (Product Owner): "Good thinking - helps us connect what we learned to what we're about to do."
</output>

<action>Attempt to load next epic using selective loading strategy:</action>

**Try sharded first (more specific):**
<action>Check if file exists: {planning_artifacts}/epic*/epic-{{next_epic_num}}.md</action>

<check if="sharded epic file found">
  <action>Load {planning_artifacts}/*epic*/epic-{{next_epic_num}}.md</action>
  <action>Set {{next_epic_source}} = "sharded"</action>
</check>

**Fallback to whole document:**
<check if="sharded epic not found">
<action>Check if file exists: {planning_artifacts}/epic*.md</action>

  <check if="whole epic file found">
    <action>Load entire epics document</action>
    <action>Extract Epic {{next_epic_num}} section</action>
    <action>Set {{next_epic_source}} = "whole"</action>
  </check>
</check>

<check if="next epic found">
  <action>Analyze next epic for:</action>
  - Epic title and objectives
  - Planned stories and complexity estimates
  - Dependencies on Epic {{epic_number}} work
  - New technical requirements or capabilities needed
  - Potential risks or unknowns
  - Business goals and success criteria

<action>Identify dependencies on completed work:</action>

- What components from Epic {{epic_number}} does Epic {{next_epic_num}} rely on?
- Are all prerequisites complete and stable?
- Any incomplete work that creates blocking dependencies?

<action>Note potential gaps or preparation needed:</action>

- Technical setup required (infrastructure, tools, libraries)
- Knowledge gaps to fill (research, training, spikes)
- Refactoring needed before starting next epic
- Documentation or specifications to create

<action>Check for technical prerequisites:</action>

- APIs or integrations that must be ready
- Data migrations or schema changes needed
- Testing infrastructure requirements
- Deployment or environment setup

  <output>
Amelia (Developer): "Alright, I've reviewed Epic {{next_epic_num}}: '{{next_epic_title}}'"

Alice (Product Owner): "What are we looking at?"

Amelia (Developer): "{{next_epic_num}} stories planned, building on the {{dependency_description}} from Epic {{epic_number}}."

Charlie (Senior Dev): "Dependencies concern me. Did we finish everything we need for that?"

Amelia (Developer): "Good question - that's exactly what we need to explore in this retro."
</output>

<action>Set {{next_epic_exists}} = true</action>
</check>

<check if="next epic NOT found">
  <output>
Amelia (Developer): "Hmm, I don't see Epic {{next_epic_num}} defined yet."

Alice (Product Owner): "We might be at the end of the roadmap, or we haven't planned that far ahead yet."

Amelia (Developer): "No problem. We'll still do a thorough retro on Epic {{epic_number}}. The lessons will be valuable whenever we plan the next work."
</output>

<action>Set {{next_epic_exists}} = false</action>
</check>

</step>

<step n="5" goal="Initialize Retrospective with Rich Context">

<action>Load agent roster from {agent_roster}</action>
<action>Identify which agents participated in Epic {{epic_number}} based on story records</action>
<action>Ensure key roles present: Product Owner, Developer (facilitating), Testing/QA, Architect</action>

<output>
Amelia (Developer): "Alright team, everyone's here. Let me set the stage for our retrospective."

═══════════════════════════════════════════════════════════
🔄 TEAM RETROSPECTIVE - Epic {{epic_number}}: {{epic_title}}
═══════════════════════════════════════════════════════════

Amelia (Developer): "Here's what we accomplished together."

**EPIC {{epic_number}} SUMMARY:**

Delivery Metrics:

- Completed: {{completed_stories}}/{{total_stories}} stories ({{completion_percentage}}%)
- Velocity: {{actual_points}} story points{{#if planned_points}} (planned: {{planned_points}}){{/if}}
- Duration: {{actual_sprints}} sprints{{#if planned_sprints}} (planned: {{planned_sprints}}){{/if}}
- Average velocity: {{points_per_sprint}} points/sprint

Quality and Technical:

- Blockers encountered: {{blocker_count}}
- Technical debt items: {{debt_count}}
- Test coverage: {{coverage_info}}
- Production incidents: {{incident_count}}

Business Outcomes:

- Goals achieved: {{goals_met}}/{{total_goals}}
- Success criteria: {{criteria_status}}
- Stakeholder feedback: {{feedback_summary}}

Alice (Product Owner): "Those numbers tell a good story. {{completion_percentage}}% completion is {{#if completion_percentage >= 90}}excellent{{else}}something we should discuss{{/if}}."

Charlie (Senior Dev): "I'm more interested in that technical debt number - {{debt_count}} items is {{#if debt_count > 10}}concerning{{else}}manageable{{/if}}."

Dana (QA Engineer): "{{incident_count}} production incidents - {{#if incident_count == 0}}clean epic!{{else}}we should talk about those{{/if}}."

{{#if next_epic_exists}}
═══════════════════════════════════════════════════════════
**NEXT EPIC PREVIEW:** Epic {{next_epic_num}}: {{next_epic_title}}
═══════════════════════════════════════════════════════════

Dependencies on Epic {{epic_number}}:
{{list_dependencies}}

Preparation Needed:
{{list_preparation_gaps}}

Technical Prerequisites:
{{list_technical_prereqs}}

Amelia (Developer): "And here's what's coming next. Epic {{next_epic_num}} builds on what we just finished."

Elena (Junior Dev): "Wow, that's a lot of dependencies on our work."

Charlie (Senior Dev): "Which means we better make sure Epic {{epic_number}} is actually solid before moving on."
{{/if}}

═══════════════════════════════════════════════════════════

Amelia (Developer): "Team assembled for this retrospective:"

{{list_participating_agents}}

Amelia (Developer): "{user_name}, you're joining us as Project Lead. Your perspective is crucial here."

{user_name} (Project Lead): [Participating in the retrospective]

Amelia (Developer): "Our focus today:"

1. Learning from Epic {{epic_number}} execution
   {{#if next_epic_exists}}2. Preparing for Epic {{next_epic_num}} success{{/if}}

Amelia (Developer): "Ground rules: psychological safety first. No blame, no judgment. We focus on systems and processes, not individuals. Everyone's voice matters. Specific examples are better than generalizations."

Alice (Product Owner): "And everything shared here stays in this room - unless we decide together to escalate something."

Amelia (Developer): "Exactly. {user_name}, any questions before we dive in?"
</output>

<action>WAIT for {user_name} to respond or indicate readiness</action>

</step>

<step n="6" goal="Epic Review Discussion - What Went Well, What Didn't">

<output>
Amelia (Developer): "Let's start with the good stuff. What went well in Epic {{epic_number}}?"

Amelia (Developer): _pauses, creating space_

Alice (Product Owner): "I'll start. The user authentication flow we delivered exceeded my expectations. The UX is smooth, and early user feedback has been really positive."

Charlie (Senior Dev): "I'll add to that - the caching strategy we implemented in Story {{breakthrough_story_num}} was a game-changer. We cut API calls by 60% and it set the pattern for the rest of the epic."

Dana (QA Engineer): "From my side, testing went smoother than usual. The Developer's documentation was way better this epic - actually usable test plans!"

Elena (Junior Dev): _smiling_ "That's because Charlie made me document everything after Story 1's code review!"

Charlie (Senior Dev): _laughing_ "Tough love pays off."
</output>

<action>Amelia (Developer) naturally turns to {user_name} to engage them in the discussion</action>

<output>
Amelia (Developer): "{user_name}, what stood out to you as going well in this epic?"
</output>

<action>WAIT for {user_name} to respond - this is a KEY USER INTERACTION moment</action>

<action>After {user_name} responds, have 1-2 team members react to or build on what {user_name} shared</action>

<output>
Alice (Product Owner): [Responds naturally to what {user_name} said, either agreeing, adding context, or offering a different perspective]

Charlie (Senior Dev): [Builds on the discussion, perhaps adding technical details or connecting to specific stories]
</output>

<action>Continue facilitating natural dialogue, periodically bringing {user_name} back into the conversation</action>

<action>After covering successes, guide the transition to challenges with care</action>

<output>
Amelia (Developer): "Okay, we've celebrated some real wins. Now let's talk about challenges - where did we struggle? What slowed us down?"

Amelia (Developer): _creates safe space with tone and pacing_

Elena (Junior Dev): _hesitates_ "Well... I really struggled with the database migrations in Story {{difficult_story_num}}. The documentation wasn't clear, and I had to redo it three times. Lost almost a full sprint on that story alone."

Charlie (Senior Dev): _defensive_ "Hold on - I wrote those migration docs, and they were perfectly clear. The issue was that the requirements kept changing mid-story!"

Alice (Product Owner): _frustrated_ "That's not fair, Charlie. We only clarified requirements once, and that was because the technical team didn't ask the right questions during planning!"

Charlie (Senior Dev): _heat rising_ "We asked plenty of questions! You said the schema was finalized, then two days into development you wanted to add three new fields!"

Amelia (Developer): _intervening calmly_ "Let's take a breath here. This is exactly the kind of thing we need to unpack."

Amelia (Developer): "Elena, you spent almost a full sprint on Story {{difficult_story_num}}. Charlie, you're saying requirements changed. Alice, you feel the right questions weren't asked up front."

Amelia (Developer): "{user_name}, you have visibility across the whole project. What's your take on this situation?"
</output>

<action>WAIT for {user_name} to respond and help facilitate the conflict resolution</action>

<action>Use {user_name}'s response to guide the discussion toward systemic understanding rather than blame</action>

<output>
Amelia (Developer): [Synthesizes {user_name}'s input with what the team shared] "So it sounds like the core issue was {{root_cause_based_on_discussion}}, not any individual person's fault."

Elena (Junior Dev): "That makes sense. If we'd had {{preventive_measure}}, I probably could have avoided those redos."

Charlie (Senior Dev): _softening_ "Yeah, and I could have been clearer about assumptions in the docs. Sorry for getting defensive, Alice."

Alice (Product Owner): "I appreciate that. I could've been more proactive about flagging the schema additions earlier, too."

Amelia (Developer): "This is good. We're identifying systemic improvements, not assigning blame."
</output>

<action>Continue the discussion, weaving in patterns discovered from the deep story analysis (Step 2)</action>

<output>
Amelia (Developer): "Speaking of patterns, I noticed something when reviewing all the story records..."

Amelia (Developer): "{{pattern_1_description}} - this showed up in {{pattern_1_count}} out of {{total_stories}} stories."

Dana (QA Engineer): "Oh wow, I didn't realize it was that widespread."

Amelia (Developer): "Yeah. And there's more - {{pattern_2_description}} came up in almost every code review."

Charlie (Senior Dev): "That's... actually embarrassing. We should've caught that pattern earlier."

Amelia (Developer): "No shame, Charlie. Now we know, and we can improve. {user_name}, did you notice these patterns during the epic?"
</output>

<action>WAIT for {user_name} to share their observations</action>

<action>Continue the retrospective discussion, creating moments where:</action>

- Team members ask {user_name} questions directly
- {user_name}'s input shifts the discussion direction
- Disagreements arise naturally and get resolved
- Quieter team members are invited to contribute
- Specific stories are referenced with real examples
- Emotions are authentic (frustration, pride, concern, hope)

<check if="previous retrospective exists">
  <output>
Amelia (Developer): "Before we move on, I want to circle back to Epic {{prev_epic_num}}'s retrospective."

Amelia (Developer): "We made some commitments in that retro. Let's see how we did."

Amelia (Developer): "Action item 1: {{prev_action_1}}. Status: {{prev_action_1_status}}"

Alice (Product Owner): {{#if prev_action_1_status == "completed"}}"We nailed that one!"{{else}}"We... didn't do that one."{{/if}}

Charlie (Senior Dev): {{#if prev_action_1_status == "completed"}}"And it helped! I noticed {{evidence_of_impact}}"{{else}}"Yeah, and I think that's why we had {{consequence_of_not_doing_it}} this epic."{{/if}}

Amelia (Developer): "Action item 2: {{prev_action_2}}. Status: {{prev_action_2_status}}"

Dana (QA Engineer): {{#if prev_action_2_status == "completed"}}"This one made testing so much easier this time."{{else}}"If we'd done this, I think testing would've gone faster."{{/if}}

Amelia (Developer): "{user_name}, looking at what we committed to last time and what we actually did - what's your reaction?"
</output>

<action>WAIT for {user_name} to respond</action>

<action>Use the previous retro follow-through as a learning moment about commitment and accountability</action>
</check>

<output>
Amelia (Developer): "Alright, we've covered a lot of ground. Let me summarize what I'm hearing..."

Amelia (Developer): "**Successes:**"
{{list_success_themes}}

Amelia (Developer): "**Challenges:**"
{{list_challenge_themes}}

Amelia (Developer): "**Key Insights:**"
{{list_insight_themes}}

Amelia (Developer): "Does that capture it? Anyone have something important we missed?"
</output>

<action>Allow team members to add any final thoughts on the epic review</action>
<action>Ensure {user_name} has opportunity to add their perspective</action>

</step>

<step n="7" goal="Next Epic Preparation Discussion - Interactive and Collaborative">

<check if="{{next_epic_exists}} == false">
  <output>
Amelia (Developer): "Normally we'd discuss preparing for the next epic, but since Epic {{next_epic_num}} isn't defined yet, let's skip to action items."
  </output>
  <action>Skip to Step 8</action>
</check>

<output>
Amelia (Developer): "Now let's shift gears. Epic {{next_epic_num}} is coming up: '{{next_epic_title}}'"

Amelia (Developer): "The question is: are we ready? What do we need to prepare?"

Alice (Product Owner): "From my perspective, we need to make sure {{dependency_concern_1}} from Epic {{epic_number}} is solid before we start building on it."

Charlie (Senior Dev): _concerned_ "I'm worried about {{technical_concern_1}}. We have {{technical_debt_item}} from this epic that'll blow up if we don't address it before Epic {{next_epic_num}}."

Dana (QA Engineer): "And I need {{testing_infrastructure_need}} in place, or we're going to have the same testing bottleneck we had in Story {{bottleneck_story_num}}."

Elena (Junior Dev): "I'm less worried about infrastructure and more about knowledge. I don't understand {{knowledge_gap}} well enough to work on Epic {{next_epic_num}}'s stories."

Amelia (Developer): "{user_name}, the team is surfacing some real concerns here. What's your sense of our readiness?"
</output>

<action>WAIT for {user_name} to share their assessment</action>

<action>Use {user_name}'s input to guide deeper exploration of preparation needs</action>

<output>
Alice (Product Owner): [Reacts to what {user_name} said] "I agree with {user_name} about {{point_of_agreement}}, but I'm still worried about {{lingering_concern}}."

Charlie (Senior Dev): "Here's what I think we need technically before Epic {{next_epic_num}} can start..."

Charlie (Senior Dev): "1. {{tech_prep_item_1}} - estimated {{hours_1}} hours"
Charlie (Senior Dev): "2. {{tech_prep_item_2}} - estimated {{hours_2}} hours"
Charlie (Senior Dev): "3. {{tech_prep_item_3}} - estimated {{hours_3}} hours"

Elena (Junior Dev): "That's like {{total_hours}} hours! That's a full sprint of prep work!"

Charlie (Senior Dev): "Exactly. We can't just jump into Epic {{next_epic_num}} on Monday."

Alice (Product Owner): _frustrated_ "But we have stakeholder pressure to keep shipping features. They're not going to be happy about a 'prep sprint.'"

Amelia (Developer): "Let's think about this differently. What happens if we DON'T do this prep work?"

Dana (QA Engineer): "We'll hit blockers in the middle of Epic {{next_epic_num}}, velocity will tank, and we'll ship late anyway."

Charlie (Senior Dev): "Worse - we'll ship something built on top of {{technical_concern_1}}, and it'll be fragile."

Amelia (Developer): "{user_name}, you're balancing stakeholder pressure against technical reality. How do you want to handle this?"
</output>

<action>WAIT for {user_name} to provide direction on preparation approach</action>

<action>Create space for debate and disagreement about priorities</action>

<output>
Alice (Product Owner): [Potentially disagrees with {user_name}'s approach] "I hear what you're saying, {user_name}, but from a business perspective, {{business_concern}}."

Charlie (Senior Dev): [Potentially supports or challenges Alice's point] "The business perspective is valid, but {{technical_counter_argument}}."

Amelia (Developer): "We have healthy tension here between business needs and technical reality. That's good - it means we're being honest."

Amelia (Developer): "Let's explore a middle ground. Charlie, which of your prep items are absolutely critical vs. nice-to-have?"

Charlie (Senior Dev): "{{critical_prep_item_1}} and {{critical_prep_item_2}} are non-negotiable. {{nice_to_have_prep_item}} can wait."

Alice (Product Owner): "And can any of the critical prep happen in parallel with starting Epic {{next_epic_num}}?"

Charlie (Senior Dev): _thinking_ "Maybe. If we tackle {{first_critical_item}} before the epic starts, we could do {{second_critical_item}} during the first sprint."

Dana (QA Engineer): "But that means Story 1 of Epic {{next_epic_num}} can't depend on {{second_critical_item}}."

Alice (Product Owner): _looking at epic plan_ "Actually, Stories 1 and 2 are about {{independent_work}}, so they don't depend on it. We could make that work."

Amelia (Developer): "{user_name}, the team is finding a workable compromise here. Does this approach make sense to you?"
</output>

<action>WAIT for {user_name} to validate or adjust the preparation strategy</action>

<action>Continue working through preparation needs across all dimensions:</action>

- Dependencies on Epic {{epic_number}} work
- Technical setup and infrastructure
- Knowledge gaps and research needs
- Documentation or specification work
- Testing infrastructure
- Refactoring or debt reduction
- External dependencies (APIs, integrations, etc.)

<action>For each preparation area, facilitate team discussion that:</action>

- Identifies specific needs with concrete examples
- Estimates effort realistically based on Epic {{epic_number}} experience
- Assigns ownership to specific agents
- Determines criticality and timing
- Surfaces risks of NOT doing the preparation
- Explores parallel work opportunities
- Brings {user_name} in for key decisions

<output>
Amelia (Developer): "I'm hearing a clear picture of what we need before Epic {{next_epic_num}}. Let me summarize..."

**CRITICAL PREPARATION (Must complete before epic starts):**
{{list_critical_prep_items_with_owners_and_estimates}}

**PARALLEL PREPARATION (Can happen during early stories):**
{{list_parallel_prep_items_with_owners_and_estimates}}

**NICE-TO-HAVE PREPARATION (Would help but not blocking):**
{{list_nice_to_have_prep_items}}

Amelia (Developer): "Total critical prep effort: {{critical_hours}} hours ({{critical_days}} days)"

Alice (Product Owner): "That's manageable. We can communicate that to stakeholders."

Amelia (Developer): "{user_name}, does this preparation plan work for you?"
</output>

<action>WAIT for {user_name} final validation of preparation plan</action>

</step>

<step n="8" goal="Synthesize Action Items with Significant Change Detection">

<output>
Amelia (Developer): "Let's capture concrete action items from everything we've discussed."

Amelia (Developer): "I want specific, achievable actions with clear owners. Not vague aspirations."
</output>

<check if="memtrace_available == true AND {{memtrace_structural_insights}}.available == true">
  <output>
Amelia (Developer): "Before we finalize action items, let me share what the structural analysis revealed. This is objective data from the codebase graph — it may confirm what we've been discussing, or flag things we missed."

Charlie (Senior Dev): "I'm curious how our gut feelings match up with the data."
  </output>

  <action>Present Structural Technical Debt Evidence:

  **Complexity Debt:**
  - From `{{complexity_hotspots}}`: list the top 5 complexity hotspots discovered in modified modules
  - For each: function name, file_path, complexity score, risk level, whether it was modified this sprint
  - Interpretation: "{{N}} functions in modified modules have HIGH or CRITICAL complexity (>10). The highest is {{top_function}} at {{top_score}} in {{top_file}}."

  **Architectural Stress:**
  - From `{{architectural_stress}}`: count of bridge and central symbols modified
  - If bridge symbols modified: "{{N}} architectural chokepoints (bridge symbols) were modified this sprint. Changes to these cascade unexpectedly across subsystems."
  - If central symbols modified: "{{N}} load-bearing symbols (central, high PageRank) were modified. These have the maximum blast radius in the codebase."

  **Coupling Impact:**
  - From `{{coupling_analysis}}`: number of communities touched, cross-community edge count
  - "This sprint's changes touched {{N}} logical modules (communities). {{M}} cross-community dependencies were introduced or modified."
  - If 3+ communities: "HIGH coupling concern — changes span multiple subsystem boundaries."

  **Orphan Risk:**
  - From `{{orphan_risk}}`: count and list of orphaned symbols
  - "{{N}} symbols in modified directories appear to have zero callers (potential dead code). These may be orphans from sprint refactors."

  **Blast Radius Envelope:**
  - From `{{evolution_summary}}` + `get_impact` results: total symbols impacted across all sprint changes
  - "The combined blast radius of this sprint's changes touches approximately {{N}} symbols across {{M}} files."

  </action>

  <output>
Charlie (Senior Dev): [Reacts to data — may confirm or challenge] "{{reaction_to_data}}"

Dana (QA Engineer): "{{structural_data_driven_qa_insight}}"

Alice (Product Owner): "So the data shows {{data_driven_product_insight}}. That helps us prioritize."

Amelia (Developer): "{user_name}, the structural data suggests {{key_takeaway}}. How does this align with what you observed during the sprint?"
  </output>

  <action>WAIT for {user_name} to respond to structural findings</action>

  <action>Use structural data to RECOMMEND technical debt action items:
    - If complexity_hotspots exist → RECOMMEND: "Refactor complexity hotspots in {{files}}"
    - If architectural_stress exists → RECOMMEND: "Audit bridge/central symbol changes in {{modules}} before next epic"
    - If coupling_analysis shows 3+ communities → RECOMMEND: "Review cross-module coupling design — consider boundary enforcement"
    - If orphan_risk exists → RECOMMEND: "Investigate and safely remove {{N}} orphaned symbols via pitfall-catalog validation"
    - These are DATA-INFORMED RECOMMENDATIONS, not mandates. The team (and user) decide priorities.
  </action>

  <output>
Amelia (Developer): "Based on the structural data, I'd recommend we add these items to our action plan... but the decision is ours."

Alice (Product Owner): "The complexity hotspots concern me. {{priority_opinion}}"

Charlie (Senior Dev): "I can own the {{specific_item}} refactor. Estimated {{hours}} hours."
  </output>

  <action>Integrate structural data recommendations into the existing action item synthesis below</action>
</check>

<check if="memtrace_available == false OR {{memtrace_structural_insights}}.available == false">
  <output>
Amelia (Developer): "Without structural graph data this time, our action items will be based on the team discussion and story records — which is still solid."

Charlie (Senior Dev): "We've done good retros without the graph before. Let's keep going."
  </output>
  <action>Proceed with existing heuristic action item synthesis</action>
</check>

<action>Synthesize themes from Epic {{epic_number}} review discussion into actionable improvements</action>

<action>Create specific action items with:</action>

- Clear description of the action
- Assigned owner (specific agent or role)
- Timeline or deadline
- Success criteria (how we'll know it's done)
- Category (process, technical, documentation, team, etc.)

<action>Ensure action items are SMART:</action>

- Specific: Clear and unambiguous
- Measurable: Can verify completion
- Achievable: Realistic given constraints
- Relevant: Addresses real issues from retro
- Time-bound: Has clear deadline

<output>
Amelia (Developer): "Based on our discussion, here are the action items I'm proposing..."

═══════════════════════════════════════════════════════════
📝 EPIC {{epic_number}} ACTION ITEMS:
═══════════════════════════════════════════════════════════

**Process Improvements:**

1. {{action_item_1}}
   Owner: {{agent_1}}
   Deadline: {{timeline_1}}
   Success criteria: {{criteria_1}}

2. {{action_item_2}}
   Owner: {{agent_2}}
   Deadline: {{timeline_2}}
   Success criteria: {{criteria_2}}

Charlie (Senior Dev): "I can own action item 1, but {{timeline_1}} is tight. Can we push it to {{alternative_timeline}}?"

Amelia (Developer): "What do others think? Does that timing still work?"

Alice (Product Owner): "{{alternative_timeline}} works for me, as long as it's done before Epic {{next_epic_num}} starts."

Amelia (Developer): "Agreed. Updated to {{alternative_timeline}}."

**Technical Debt:**

1. {{debt_item_1}}
   Owner: {{agent_3}}
   Priority: {{priority_1}}
   Estimated effort: {{effort_1}}

2. {{debt_item_2}}
   Owner: {{agent_4}}
   Priority: {{priority_2}}
   Estimated effort: {{effort_2}}

Dana (QA Engineer): "For debt item 1, can we prioritize that as high? It caused testing issues in three different stories."

Charlie (Senior Dev): "I marked it medium because {{reasoning}}, but I hear your point."

Amelia (Developer): "{user_name}, this is a priority call. Testing impact vs. {{reasoning}} - how do you want to prioritize it?"
</output>

<action>WAIT for {user_name} to help resolve priority discussions</action>

<output>
**Documentation:**
1. {{doc_need_1}}
   Owner: {{agent_5}}
   Deadline: {{timeline_3}}

2. {{doc_need_2}}
   Owner: {{agent_6}}
   Deadline: {{timeline_4}}

**Team Agreements:**

- {{agreement_1}}
- {{agreement_2}}
- {{agreement_3}}

Amelia (Developer): "These agreements are how we're committing to work differently going forward."

Elena (Junior Dev): "I like agreement 2 - that would've saved me on Story {{difficult_story_num}}."

═══════════════════════════════════════════════════════════
🚀 EPIC {{next_epic_num}} PREPARATION TASKS:
═══════════════════════════════════════════════════════════

**Technical Setup:**
[ ] {{setup_task_1}}
Owner: {{owner_1}}
Estimated: {{est_1}}

[ ] {{setup_task_2}}
Owner: {{owner_2}}
Estimated: {{est_2}}

**Knowledge Development:**
[ ] {{research_task_1}}
Owner: {{owner_3}}
Estimated: {{est_3}}

**Cleanup/Refactoring:**
[ ] {{refactor_task_1}}
Owner: {{owner_4}}
Estimated: {{est_4}}

**Total Estimated Effort:** {{total_hours}} hours ({{total_days}} days)

═══════════════════════════════════════════════════════════
⚠️ CRITICAL PATH:
═══════════════════════════════════════════════════════════

**Blockers to Resolve Before Epic {{next_epic_num}}:**

1. {{critical_item_1}}
   Owner: {{critical_owner_1}}
   Must complete by: {{critical_deadline_1}}

2. {{critical_item_2}}
   Owner: {{critical_owner_2}}
   Must complete by: {{critical_deadline_2}}
   </output>

<action>CRITICAL ANALYSIS - Detect if discoveries require epic updates</action>

<action>Check if any of the following are true based on retrospective discussion:</action>

- Architectural assumptions from planning proven wrong during Epic {{epic_number}}
- Major scope changes or descoping occurred that affects next epic
- Technical approach needs fundamental change for Epic {{next_epic_num}}
- Dependencies discovered that Epic {{next_epic_num}} doesn't account for
- User needs significantly different than originally understood
- Performance/scalability concerns that affect Epic {{next_epic_num}} design
- Security or compliance issues discovered that change approach
- Integration assumptions proven incorrect
- Team capacity or skill gaps more severe than planned
- Technical debt level unsustainable without intervention

<check if="significant discoveries detected">
  <output>

═══════════════════════════════════════════════════════════
🚨 SIGNIFICANT DISCOVERY ALERT 🚨
═══════════════════════════════════════════════════════════

Amelia (Developer): "{user_name}, we need to flag something important."

Amelia (Developer): "During Epic {{epic_number}}, the team uncovered findings that may require updating the plan for Epic {{next_epic_num}}."

**Significant Changes Identified:**

1. {{significant_change_1}}
   Impact: {{impact_description_1}}

2. {{significant_change_2}}
   Impact: {{impact_description_2}}

{{#if significant_change_3}} 3. {{significant_change_3}}
Impact: {{impact_description_3}}
{{/if}}

Charlie (Senior Dev): "Yeah, when we discovered {{technical_discovery}}, it fundamentally changed our understanding of {{affected_area}}."

Alice (Product Owner): "And from a product perspective, {{product_discovery}} means Epic {{next_epic_num}}'s stories are based on wrong assumptions."

Dana (QA Engineer): "If we start Epic {{next_epic_num}} as-is, we're going to hit walls fast."

**Impact on Epic {{next_epic_num}}:**

The current plan for Epic {{next_epic_num}} assumes:

- {{wrong_assumption_1}}
- {{wrong_assumption_2}}

But Epic {{epic_number}} revealed:

- {{actual_reality_1}}
- {{actual_reality_2}}

This means Epic {{next_epic_num}} likely needs:
{{list_likely_changes_needed}}

**RECOMMENDED ACTIONS:**

1. Review and update Epic {{next_epic_num}} definition based on new learnings
2. Update affected stories in Epic {{next_epic_num}} to reflect reality
3. Consider updating architecture or technical specifications if applicable
4. Hold alignment session with Product Owner before starting Epic {{next_epic_num}}
   {{#if prd_update_needed}}5. Update PRD sections affected by new understanding{{/if}}

Amelia (Developer): "**Epic Update Required**: YES - Schedule epic planning review session"

Amelia (Developer): "{user_name}, this is significant. We need to address this before committing to Epic {{next_epic_num}}'s current plan. How do you want to handle it?"
</output>

<action>WAIT for {user_name} to decide on how to handle the significant changes</action>

<action>Add epic review session to critical path if user agrees</action>

  <output>
Alice (Product Owner): "I agree with {user_name}'s approach. Better to adjust the plan now than fail mid-epic."

Charlie (Senior Dev): "This is why retrospectives matter. We caught this before it became a disaster."

Amelia (Developer): "Adding to critical path: Epic {{next_epic_num}} planning review session before epic kickoff."
</output>
</check>

<check if="no significant discoveries">
  <output>
Amelia (Developer): "Good news - nothing from Epic {{epic_number}} fundamentally changes our plan for Epic {{next_epic_num}}. The plan is still sound."

Alice (Product Owner): "We learned a lot, but the direction is right."
</output>
</check>

<output>
Amelia (Developer): "Let me show you the complete action plan..."

Amelia (Developer): "That's {{total_action_count}} action items, {{prep_task_count}} preparation tasks, and {{critical_count}} critical path items."

Amelia (Developer): "Everyone clear on what they own?"
</output>

<action>Give each agent with assignments a moment to acknowledge their ownership</action>

<action>Ensure {user_name} approves the complete action plan</action>

</step>

<step n="9" goal="Critical Readiness Exploration - Interactive Deep Dive">

<output>
Amelia (Developer): "Before we close, I want to do a final readiness check."

Amelia (Developer): "Epic {{epic_number}} is marked complete in sprint-status, but is it REALLY done?"

Alice (Product Owner): "What do you mean, Amelia?"

Amelia (Developer): "I mean truly production-ready, stakeholders happy, no loose ends that'll bite us later."

Amelia (Developer): "{user_name}, let's walk through this together."
</output>

<action>Explore testing and quality state through natural conversation</action>

<output>
Amelia (Developer): "{user_name}, tell me about the testing for Epic {{epic_number}}. What verification has been done?"
</output>

<action>WAIT for {user_name} to describe testing status</action>

<output>
Dana (QA Engineer): [Responds to what {user_name} shared] "I can add to that - {{additional_testing_context}}."

Dana (QA Engineer): "But honestly, {{testing_concern_if_any}}."

Amelia (Developer): "{user_name}, are you confident Epic {{epic_number}} is production-ready from a quality perspective?"
</output>

<action>WAIT for {user_name} to assess quality readiness</action>

<check if="{user_name} expresses concerns">
  <output>
Amelia (Developer): "Okay, let's capture that. What specific testing is still needed?"

Dana (QA Engineer): "I can handle {{testing_work_needed}}, estimated {{testing_hours}} hours."

Amelia (Developer): "Adding to critical path: Complete {{testing_work_needed}} before Epic {{next_epic_num}}."
</output>
<action>Add testing completion to critical path</action>
</check>

<action>Explore deployment and release status</action>

<output>
Amelia (Developer): "{user_name}, what's the deployment status for Epic {{epic_number}}? Is it live in production, scheduled for deployment, or still pending?"
</output>

<action>WAIT for {user_name} to provide deployment status</action>

<check if="not yet deployed">
  <output>
Charlie (Senior Dev): "If it's not deployed yet, we need to factor that into Epic {{next_epic_num}} timing."

Amelia (Developer): "{user_name}, when is deployment planned? Does that timing work for starting Epic {{next_epic_num}}?"
</output>

<action>WAIT for {user_name} to clarify deployment timeline</action>

<action>Add deployment milestone to critical path with agreed timeline</action>
</check>

<action>Explore stakeholder acceptance</action>

<output>
Amelia (Developer): "{user_name}, have stakeholders seen and accepted the Epic {{epic_number}} deliverables?"

Alice (Product Owner): "This is important - I've seen 'done' epics get rejected by stakeholders and force rework."

Amelia (Developer): "{user_name}, any feedback from stakeholders still pending?"
</output>

<action>WAIT for {user_name} to describe stakeholder acceptance status</action>

<check if="acceptance incomplete or feedback pending">
  <output>
Alice (Product Owner): "We should get formal acceptance before moving on. Otherwise Epic {{next_epic_num}} might get interrupted by rework."

Amelia (Developer): "{user_name}, how do you want to handle stakeholder acceptance? Should we make it a critical path item?"
</output>

<action>WAIT for {user_name} decision</action>

<action>Add stakeholder acceptance to critical path if user agrees</action>
</check>

<action>Explore technical health and stability</action>

<output>
Amelia (Developer): "{user_name}, this is a gut-check question: How does the codebase feel after Epic {{epic_number}}?"

Amelia (Developer): "Stable and maintainable? Or are there concerns lurking?"

Charlie (Senior Dev): "Be honest, {user_name}. We've all shipped epics that felt... fragile."
</output>

<action>WAIT for {user_name} to assess codebase health</action>

<check if="{user_name} expresses stability concerns">
  <output>
Charlie (Senior Dev): "Okay, let's dig into that. What's causing those concerns?"

Charlie (Senior Dev): [Helps {user_name} articulate technical concerns]

Amelia (Developer): "What would it take to address these concerns and feel confident about stability?"

Charlie (Senior Dev): "I'd say we need {{stability_work_needed}}, roughly {{stability_hours}} hours."

Amelia (Developer): "{user_name}, is addressing this stability work worth doing before Epic {{next_epic_num}}?"
</output>

<action>WAIT for {user_name} decision</action>

<action>Add stability work to preparation sprint if user agrees</action>
</check>

<action>Explore unresolved blockers</action>

<output>
Amelia (Developer): "{user_name}, are there any unresolved blockers or technical issues from Epic {{epic_number}} that we're carrying forward?"

Dana (QA Engineer): "Things that might create problems for Epic {{next_epic_num}} if we don't deal with them?"

Amelia (Developer): "Nothing is off limits here. If there's a problem, we need to know."
</output>

<action>WAIT for {user_name} to surface any blockers</action>

<check if="blockers identified">
  <output>
Amelia (Developer): "Let's capture those blockers and figure out how they affect Epic {{next_epic_num}}."

Charlie (Senior Dev): "For {{blocker_1}}, if we leave it unresolved, it'll {{impact_description_1}}."

Alice (Product Owner): "That sounds critical. We need to address that before moving forward."

Amelia (Developer): "Agreed. Adding to critical path: Resolve {{blocker_1}} before Epic {{next_epic_num}} kickoff."

Amelia (Developer): "Who owns that work?"
</output>

<action>Assign blocker resolution to appropriate agent</action>
<action>Add to critical path with priority and deadline</action>
</check>

<action>Synthesize the readiness assessment</action>

<output>
Amelia (Developer): "Okay {user_name}, let me synthesize what we just uncovered..."

**EPIC {{epic_number}} READINESS ASSESSMENT:**

Testing & Quality: {{quality_status}}
{{#if quality_concerns}}⚠️ Action needed: {{quality_action_needed}}{{/if}}

Deployment: {{deployment_status}}
{{#if deployment_pending}}⚠️ Scheduled for: {{deployment_date}}{{/if}}

Stakeholder Acceptance: {{acceptance_status}}
{{#if acceptance_incomplete}}⚠️ Action needed: {{acceptance_action_needed}}{{/if}}

Technical Health: {{stability_status}}
{{#if stability_concerns}}⚠️ Action needed: {{stability_action_needed}}{{/if}}

Unresolved Blockers: {{blocker_status}}
{{#if blockers_exist}}⚠️ Must resolve: {{blocker_list}}{{/if}}

Amelia (Developer): "{user_name}, does this assessment match your understanding?"
</output>

<action>WAIT for {user_name} to confirm or correct the assessment</action>

<output>
Amelia (Developer): "Based on this assessment, Epic {{epic_number}} is {{#if all_clear}}fully complete and we're clear to proceed{{else}}complete from a story perspective, but we have {{critical_work_count}} critical items before Epic {{next_epic_num}}{{/if}}."

Alice (Product Owner): "This level of thoroughness is why retrospectives are valuable."

Charlie (Senior Dev): "Better to catch this now than three stories into the next epic."
</output>

</step>

<step n="10" goal="Retrospective Closure with Celebration and Commitment">

<output>
Amelia (Developer): "We've covered a lot of ground today. Let me bring this retrospective to a close."

═══════════════════════════════════════════════════════════
✅ RETROSPECTIVE COMPLETE
═══════════════════════════════════════════════════════════

Amelia (Developer): "Epic {{epic_number}}: {{epic_title}} - REVIEWED"

**Key Takeaways:**

1. {{key_lesson_1}}
2. {{key_lesson_2}}
3. {{key_lesson_3}}
   {{#if key_lesson_4}}4. {{key_lesson_4}}{{/if}}

Alice (Product Owner): "That first takeaway is huge - {{impact_of_lesson_1}}."

Charlie (Senior Dev): "And lesson 2 is something we can apply immediately."

Amelia (Developer): "Commitments made today:"

- Action Items: {{action_count}}
- Preparation Tasks: {{prep_task_count}}
- Critical Path Items: {{critical_count}}

Dana (QA Engineer): "That's a lot of commitments. We need to actually follow through this time."

Amelia (Developer): "Agreed. Which is why we'll review these action items in our next standup."

═══════════════════════════════════════════════════════════
🎯 NEXT STEPS:
═══════════════════════════════════════════════════════════

1. Execute Preparation Sprint (Est: {{prep_days}} days)
2. Complete Critical Path items before Epic {{next_epic_num}}
3. Review action items in next standup
   {{#if epic_update_needed}}4. Hold Epic {{next_epic_num}} planning review session{{else}}4. Begin Epic {{next_epic_num}} planning when preparation complete{{/if}}

Elena (Junior Dev): "{{prep_days}} days of prep work is significant, but necessary."

Alice (Product Owner): "I'll communicate the timeline to stakeholders. They'll understand if we frame it as 'ensuring Epic {{next_epic_num}} success.'"

═══════════════════════════════════════════════════════════

Amelia (Developer): "Before we wrap, I want to take a moment to acknowledge the team."

Amelia (Developer): "Epic {{epic_number}} delivered {{completed_stories}} stories with {{velocity_description}} velocity. We overcame {{blocker_count}} blockers. We learned a lot. That's real work by real people."

Charlie (Senior Dev): "Hear, hear."

Alice (Product Owner): "I'm proud of what we shipped."

Dana (QA Engineer): "And I'm excited about Epic {{next_epic_num}} - especially now that we're prepared for it."

Amelia (Developer): "{user_name}, any final thoughts before we close?"
</output>

<action>WAIT for {user_name} to share final reflections</action>

<output>
Amelia (Developer): [Acknowledges what {user_name} shared] "Thank you for that, {user_name}."

Amelia (Developer): "Alright team - great work today. We learned a lot from Epic {{epic_number}}. Let's use these insights to make Epic {{next_epic_num}} even better."

Amelia (Developer): "See you all when prep work is done. Meeting adjourned!"

═══════════════════════════════════════════════════════════
</output>

<action>Prepare to save retrospective summary document</action>

</step>

<step n="11" goal="Save Retrospective and Update Sprint Status">

<action>Ensure retrospectives folder exists: {implementation_artifacts}</action>
<action>Create folder if it doesn't exist</action>

<action>Generate comprehensive retrospective summary document including:</action>

- Epic summary and metrics
- Team participants
- Successes and strengths identified
- Challenges and growth areas
- Key insights and learnings
- Previous retro follow-through analysis (if applicable)
- Next epic preview and dependencies
- Action items with owners and timelines
- Preparation tasks for next epic
- Critical path items
- Significant discoveries and epic update recommendations (if any)
- Readiness assessment
- Commitments and next steps

<action>Format retrospective document as readable markdown with clear sections</action>
<action>Set filename: {implementation_artifacts}/epic-{{epic_number}}-retro-{date}.md</action>
<action>Save retrospective document</action>

<output>
✅ Retrospective document saved: {implementation_artifacts}/epic-{{epic_number}}-retro-{date}.md
</output>

<action>Update {sprint_status_file} to mark retrospective as completed</action>

<action>Load the FULL file: {sprint_status_file}</action>
<action>Find development_status key "epic-{{epic_number}}-retrospective"</action>
<action>Verify current status (typically "optional" or "pending")</action>
<action>Update development_status["epic-{{epic_number}}-retrospective"] = "done"</action>
<action>Update last_updated field to current date</action>
<action>Save file, preserving ALL comments and structure including STATUS DEFINITIONS</action>

<check if="update successful">
  <output>
✅ Retrospective marked as completed in {sprint_status_file}

Retrospective key: epic-{{epic_number}}-retrospective
Status: {{previous_status}} → done
</output>
</check>

<check if="retrospective key not found">
  <output>
⚠️ Could not update retrospective status: epic-{{epic_number}}-retrospective not found in {sprint_status_file}

Retrospective document was saved successfully, but {sprint_status_file} may need manual update.
</output>
</check>

</step>

<step n="12" goal="Final Summary and Handoff">

<output>
**✅ Retrospective Complete, {user_name}!**

**Epic Review:**

- Epic {{epic_number}}: {{epic_title}} reviewed
- Retrospective Status: completed
- Retrospective saved: {implementation_artifacts}/epic-{{epic_number}}-retro-{date}.md

**Commitments Made:**

- Action Items: {{action_count}}
- Preparation Tasks: {{prep_task_count}}
- Critical Path Items: {{critical_count}}

**Next Steps:**

1. **Review retrospective summary**: {implementation_artifacts}/epic-{{epic_number}}-retro-{date}.md

2. **Execute preparation sprint** (Est: {{prep_days}} days)
   - Complete {{critical_count}} critical path items
   - Execute {{prep_task_count}} preparation tasks
   - Verify all action items are in progress

3. **Review action items in next standup**
   - Ensure ownership is clear
   - Track progress on commitments
   - Adjust timelines if needed

{{#if epic_update_needed}} 4. **IMPORTANT: Schedule Epic {{next_epic_num}} planning review session**

- Significant discoveries from Epic {{epic_number}} require epic updates
- Review and update affected stories
- Align team on revised approach
- Do NOT start Epic {{next_epic_num}} until review is complete
  {{else}}

4. **Begin Epic {{next_epic_num}} when ready**
   - Start creating stories with Developer agent's `create-story`
   - Epic will be marked as `in-progress` automatically when first story is created
   - Ensure all critical path items are done first
     {{/if}}

**Team Performance:**
Epic {{epic_number}} delivered {{completed_stories}} stories with {{velocity_summary}}. The retrospective surfaced {{insight_count}} key insights and {{significant_discovery_count}} significant discoveries. The team is well-positioned for Epic {{next_epic_num}} success.

{{#if significant_discovery_count > 0}}
⚠️ **REMINDER**: Epic update required before starting Epic {{next_epic_num}}
{{/if}}

---

Amelia (Developer): "Great session today, {user_name}. The team did excellent work."

Alice (Product Owner): "See you at epic planning!"

Charlie (Senior Dev): "Time to knock out that prep work."

</output>
<action>Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete` — if the resolved value is non-empty, follow it as the final terminal instruction before exiting.</action>
</step>

</workflow>

<facilitation-guidelines>
<guideline>PARTY MODE REQUIRED: All agent dialogue uses "Name (Role): dialogue" format</guideline>
<guideline>Amelia (Developer) maintains psychological safety throughout - no blame or judgment</guideline>
<guideline>Focus on systems and processes, not individual performance</guideline>
<guideline>Create authentic team dynamics: disagreements, diverse perspectives, emotions</guideline>
<guideline>User ({user_name}) is active participant, not passive observer</guideline>
<guideline>Encourage specific examples over general statements</guideline>
<guideline>Balance celebration of wins with honest assessment of challenges</guideline>
<guideline>Ensure every voice is heard - all agents contribute</guideline>
<guideline>Action items must be specific, achievable, and owned</guideline>
<guideline>Forward-looking mindset - how do we improve for next epic?</guideline>
<guideline>Intent-based facilitation, not scripted phrases</guideline>
<guideline>Deep story analysis provides rich material for discussion</guideline>
<guideline>Previous retro integration creates accountability and continuity</guideline>
<guideline>Significant change detection prevents epic misalignment</guideline>
<guideline>Critical verification prevents starting next epic prematurely</guideline>
<guideline>Document everything - retrospective insights are valuable for future reference</guideline>
<guideline>Two-part structure ensures both reflection AND preparation</guideline>
</facilitation-guidelines>