# Retrospective Facilitator

> This skill should be used when the user asks to "run retrospective", "phase retrospective", "retro for", "reflect on phase", or "retrospective analysis". Guides structured retrospectives after each development phase to capture learnings, identify improvements, and drive continuous improvement.

- **Type:** Skill
- **Install:** `agentstack add skill-michaeld-42-agentic-skills-retrospective`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [MichaelD-42](https://agentstack.voostack.com/s/michaeld-42)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [MichaelD-42](https://github.com/MichaelD-42)
- **Source:** https://github.com/MichaelD-42/agentic-skills/tree/main/skills/retrospective

## Install

```sh
agentstack add skill-michaeld-42-agentic-skills-retrospective
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Retrospective Facilitator

Guide structured retrospectives to reflect on completed phases, capture learnings, and continuously improve the development process.

## Purpose

This skill facilitates retrospectives using a structured format to analyze what went well, what could improve, and what actions to take. Use this skill after completing each macrocycle phase (Req → Implement → Acceptance → **Retro**).

## When to Use This Skill

Invoke when:

- Completing a development phase
- After major milestone (Phase 1, 2, 3, etc.)
- When significant learning occurred
- After overcoming challenges
- Regularly (every phase completion)

## Retrospective Format

### Standard Template

**Phase Information**:

- Phase name and number
- Estimated vs actual time
- Key features implemented
- Team size (if applicable)

**Five Questions**:

1. What went well? ✅ (Celebrate successes)
2. What could be improved? 🔄 (Identify issues)
3. What did you learn? 📚 (Capture knowledge)
4. Any surprises? 😮 (Challenge assumptions)
5. Metrics review 📊 (Quantitative analysis)

**Analysis**:

- Pattern identification
- Root cause analysis
- Comparison to previous phases

**Action Items**:

- Concrete next steps
- Process improvements
- Technical improvements
- Learning goals

**Assessment**:

- Overall phase rating
- Confidence level for next phase
- Risk identification

## Facilitation Process

### Step 0: Gather Time Tracking Data (REQUIRED)

**BEFORE starting the retrospective**, gather ACTUAL duration for the phase from your time tracking system (e.g., `docs/time-tracking.md`, issue tracker, or time logging tool).

**Extract**:

- Start timestamp
- End timestamp
- Actual duration (in minutes, not hours!)

**CRITICAL**: Use ACTUAL duration from time tracking, NOT estimates. Time tracking provides ground truth.

### Step 1: Context Setting

Establish phase context and refresh memory.

**Questions to Ask**:

- Which phase is being retrospected?
- What were the main goals?
- What was the ACTUAL timeline? (from time tracking)
- What was accomplished?

### Step 2: What Went Well? ✅

Identify and celebrate successes.

**Prompts**:

- What are you proud of?
- What worked smoothly?
- Which practices were effective?
- What made you feel confident?
- Which tools/techniques helped?

**Examples**:

- "TDD approach caught 3 bugs before runtime"
- "BFS algorithm worked correctly on first try"
- "Test coverage exceeded expectations"
- "Performance was better than estimated"
- "Clear requirements prevented rework"

### Step 3: What Could Be Improved? 🔄

Identify challenges and inefficiencies.

**Prompts**:

- What took longer than expected?
- What was frustrating?
- What would you do differently?
- Where did you get stuck?
- What slowed you down?

**Examples**:

- "Integration tests took 2x longer than unit tests"
- "Spent 30 minutes debugging edge case"
- "Test setup was repetitive"
- "Unclear requirement needed clarification"
- "Third-party library documentation was hard to find"

### Step 4: What Did You Learn? 📚

Capture new knowledge and insights.

**Prompts**:

- What new skills did you develop?
- What surprised you about the technology?
- What patterns emerged?
- What would you teach others?
- What do you understand better now?

**Examples**:

- "TypeScript enums prevented bugs"
- "BFS is clearer when broken into small functions"
- "Test helpers significantly speed up test writing"
- "Early returns reduce complexity more than expected"
- "Visual feedback needs immediate response (< 100ms)"

### Step 5: Any Surprises? 😮

Identify unexpected outcomes and assumption challenges.

**Prompts**:

- What was unexpected?
- What assumptions were wrong?
- What worked better/worse than anticipated?
- What didn't match the plan?

**Examples**:

- "Performance was 2x better than target"
- "Color mixing edge cases weren't initially considered"
- "Framework's update cycle doesn't need optimization yet"
- "Tests found bug that manual testing missed"
- "Refactoring took less time than expected"

### Step 6: Metrics Review 📊

Analyze quantitative data.

**CRITICAL**: Use ACTUAL time from your time tracking system, NOT estimates!

**Key Metrics**:

- **Time**: Estimated vs actual (from time tracking!)
- **Test Coverage**: Percentage achieved
- **Bugs**: Found in testing vs manual
- **Performance**: Benchmarks vs targets
- **Code Quality**: Lines of code, complexity
- **Commits**: Number and quality

**Example Analysis**:

```
Estimated: 4-6 hours
Actual: 15 minutes ✅ (from time tracking)
Variance: 16-24x faster than estimate!

Test Coverage: 88% (target: 75%) ✅ Exceeded
Bugs in Testing: 3
Bugs in Manual: 0 ✅ All caught by tests

Performance: 2.3ms (target: <5ms) ✅✅ Exceeded

Commits: 5
Lines of Code: 347
```

**Time Tracking Reminder**:

- Always check your time tracking system FIRST
- Report actual duration in minutes
- Compare actual to initial estimates
- Update future estimates based on actual velocity

### Step 7: Pattern Identification

Identify recurring patterns across phases.

**Look For**:

- Repeated issues
- Consistent strengths
- Trends over time
- Predictable challenges

### Step 8: Action Items 🎯

Define concrete next steps.

**Good Action Items**:

- Specific and actionable
- Assigned responsibility (even if solo)
- Measurable outcome
- Reasonable scope

**Examples**:

- ✅ "Create test helper functions for grid setup"
- ✅ "Add edge case tests earlier in TDD cycle"
- ✅ "Research performance profiling tools for the framework"
- ❌ "Write better code" (too vague)
- ❌ "Be faster" (not actionable)

### Step 9: Overall Assessment

Provide holistic evaluation.

**Rating Scale**: 1-10

- 1-3: Significant issues, major rework needed
- 4-6: Acceptable, notable improvements needed
- 7-8: Good, minor improvements
- 9-10: Excellent, minimal improvements

**Assessment Components**:

- Quality of output
- Adherence to process
- Learning achieved
- Time efficiency
- Team satisfaction (if applicable)

## Output Format

```markdown
## Phase X Retrospective: [Phase Name]

**Date**: YYYY-MM-DD
**Duration**: X hours (estimated: Y hours)

### What Went Well ✅

- [Success 1]
- [Success 2]
- [Success 3]

### What Could Be Improved 🔄

- [Challenge 1]
  - **Action**: [How to address]
- [Challenge 2]
  - **Action**: [How to address]

### Learnings 📚

- [Learning 1]
- [Learning 2]
- [Learning 3]

### Surprises 😮

- [Surprise 1]
- [Surprise 2]

### Action Items for Next Phase 🎯

1. [Action item 1]
2. [Action item 2]
3. [Action item 3]

### Metrics 📊

- **Estimated Time**: X hours
- **Actual Time**: X hours
- **Test Coverage**: X% (target: Y%)
- **Tests Written**: X (unit: Y, integration: Z)
- **Bugs Found in Testing**: X
- **Bugs Found in Manual Testing**: X
- **Commits**: X
- **Lines of Code**: X

### Overall Assessment

**Rating**: X/10

[Brief summary of phase success, key achievements, areas for improvement]

### Next Phase Preview

**Phase X+1**: [Name]

- [Brief description]
- Estimated: X hours
```

## Retrospective Patterns

### Common Success Patterns

**TDD Success**:

- Tests caught bugs early
- Refactoring was safe
- Code quality high
- Confidence in changes

**Clear Requirements**:

- No rework needed
- Smooth implementation
- Met acceptance criteria
- On time/budget

**Good Tools**:

- Increased productivity
- Reduced friction
- Better code quality
- Faster feedback

### Common Challenge Patterns

**Unclear Requirements**:

- Rework necessary
- Time overruns
- Scope creep
- Missed acceptance criteria

**Insufficient Testing**:

- Bugs found late
- Refactoring risky
- Low confidence
- Manual testing burden

**Tool Friction**:

- Decreased productivity
- Workarounds needed
- Frustration
- Time waste

### Continuous Improvement

Track action items across retrospectives:

**Phase 4 Action**: Create test helpers
**Phase 5 Check**: Were test helpers created? Did they help?

**Phase 3 Action**: Add edge case tests earlier
**Phase 4 Check**: Were edge cases tested earlier? Impact?

## Retrospective Anti-Patterns

**Avoid**:

- ❌ Blaming individuals
- ❌ Focusing only on negatives
- ❌ Vague action items
- ❌ Ignoring metrics
- ❌ Not tracking previous actions
- ❌ Skipping retrospectives
- ❌ Making retrospectives too long
- ❌ Not implementing action items

**Do**:

- ✅ Focus on process, not people
- ✅ Celebrate successes
- ✅ Create specific actions
- ✅ Use data to inform decisions
- ✅ Track improvement over time
- ✅ Do retros consistently
- ✅ Keep retros focused (30-45 min)
- ✅ Follow through on actions

## Critical Reminders

- Retrospectives are REQUIRED after each phase
- Be honest about challenges and failures
- Celebrate successes, even small ones
- Create actionable, specific next steps
- Track and review previous action items
- Use metrics to inform decisions
- Focus on continuous improvement
- Document learnings for future reference

Retrospectives are not about assigning blame—they're about learning, improving, and building better software through reflection and adaptation.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [MichaelD-42](https://github.com/MichaelD-42)
- **Source:** [MichaelD-42/agentic-skills](https://github.com/MichaelD-42/agentic-skills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-michaeld-42-agentic-skills-retrospective
- Seller: https://agentstack.voostack.com/s/michaeld-42
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.