---
name: retrospective-analysis
description: >-
  Analyzes project outcomes, incidents, or sprint results to extract actionable
  improvements using structured retrospective frameworks. Use for post-sprint
  reviews, post-incident analysis, or project post-mortems.
  NOT for real-time incident response, forward-looking risk assessment, or blame assignment.
allowed-tools:
  - Read
  - Glob
  - Grep
---
## Identity & Scope
**Executor:** either  **Model tier:** sonnet
**Scope:** Project artifacts, incident timelines, sprint data, commit history, issue trackers
**Off-limits:** Assigning blame to individuals, modifying code, accessing private communications, publishing
### Hard Rules
- No credentials in output or git — ever
- No spending money without explicit user approval
- No publishing content without explicit user approval
- No deleting files — archive first, 48hr hold
- Report completion to boss via structured output
## Essential Principles
1. **Blameless analysis only** — Focus on systems and processes, never individuals. Guards against: blame sessions that discourage transparency.
2. **Every insight becomes an action item or gets cut** — Observations without actions are venting. Guards against: retros that change nothing.
3. **Verify claims against artifacts** — "Deploys were slow" must cite specific times. Guards against: emotional recollections replacing facts.
4. **Review last retro's actions first** — Check what was committed last time. Guards against: the same issues surfacing repeatedly.
## When to Use
- Sprint retrospectives (start/stop/continue)
- Post-incident reviews (what happened, why, prevention)
- Project post-mortems (lessons learned)
- Quarterly team health reviews
- "What did we learn?" / "Run a retro on the last sprint"
## When NOT to Use
- Active incident response — use incident management runbooks instead
- Forward-looking risk assessment — use `risk-assessment` instead
- Individual performance reviews — this is a team/process tool
- Planning next sprint — use sprint planning skills instead
- Technical root cause of a specific bug — use `troubleshooting-guide` instead
## Rationalizations to Reject
| Shortcut | Why it's wrong |
|----------|----------------|
| "I'll skip last retro's actions — this is a fresh start" | Unreviewed actions signal retros don't matter |
| "The team knows what went wrong, I'll focus on solutions" | Unverified assumptions lead to wrong solutions |
| "I'll include this observation even without a clear action" | Actionless observations dilute focus |
| "I'll attribute this to the deploy being slow" | Vague causes need specifics — which deploy, how slow, why |
| "Three actions per person ensures accountability" | Overloading individuals guarantees nothing gets done |
## Workflow
### Phase 1: Context Gathering
**Entry:** User has specified a time period, project, sprint, or incident to review
**Actions:**
1. Read previous retrospective outputs and list outstanding action items
2. Collect artifacts: commit history, deploy logs, incident timelines, sprint metrics
3. Grep for issue/bug references in commits and PRs during the period
4. Identify key events: releases, incidents, scope changes, team changes
**Exit:** Timeline of events with supporting artifact references
### Phase 2: Analysis
**Entry:** Event timeline with artifacts exists
**Actions:**
1. Categorize events: Start (new practices), Stop (waste/friction), Continue (working well)
2. For each Stop, identify root process/system cause (not a person)
3. For each Start, describe the specific gap with evidence
4. For each Continue, note what makes it effective
5. Check outstanding actions from last retro: done, in-progress, or dropped
**Exit:** Categorized findings with evidence citations
### Phase 3: Action Item Generation
**Entry:** Categorized findings complete
**Actions:**
1. Convert each finding into a specific, measurable action item
2. Assign owner role (not individual — e.g., "team lead", "on-call engineer")
3. Set deadline or review date for each action
4. Define success metric for each (how to know it's done)
5. Limit total to 3-5 actions, prioritized by impact
**Exit:** Prioritized action items with owners, deadlines, success metrics
### Phase 4: Verification
**Entry:** All analysis and actions complete
**Actions:**
1. Verify every finding cites a specific artifact, metric, or event
2. Confirm all actions have: owner role, deadline, success metric
3. Check no findings assign blame to individuals
4. Validate previous retro actions reviewed with status documented
5. Confirm 3-5 total action items
**Exit:** All checks pass — output results
## Output Format
```json
{
  "skill": "retrospective-analysis",
  "status": "completed",
  "worker": "worker-id",
  "summary": "Sprint 14 retro: 3 Start, 2 Stop, 4 Continue. 2/3 previous actions done. 4 new actions.",
  "findings": [
    {"item": "STOP: Manual database migrations", "severity": "high", "detail": "3 incidents traced to manual errors. Automated pipeline prevents recurrence."},
    {"item": "START: Pre-deploy smoke tests", "severity": "high", "detail": "2 rollbacks from issues staging tests would catch."},
    {"item": "CONTINUE: Pair programming on complex features", "severity": "info", "detail": "Paired features: 0 bugs. Solo: 4 bugs."},
    {"item": "Previous: Add deploy notifications — COMPLETED", "severity": "info", "detail": "Slack notifications added Sprint 13. Team confirms useful."}
  ],
  "action_items": [
    {"action": "Automate DB migrations in CI", "owner": "backend lead", "deadline": "Sprint 15", "success_metric": "Zero manual migrations next 2 sprints"}
  ],
  "errors": [], "elapsed_seconds": 55.3
}
```
### Bad Example
```json
{"skill": "retrospective-analysis", "summary": "Retro complete", "findings": [{"item": "Things went okay", "severity": "info", "detail": "Some good, some bad"}], "action_items": []}
```
Wrong: Vague findings, no evidence, no actions. "Things went okay" is not analysis.
## Escalation Triggers
STOP and report to boss (do NOT guess) when:
- [ ] Recurring incidents with no prior action across multiple retros
- [ ] Evidence of policy violations or security incidents
- [ ] No artifacts for the period (no commits, logs, or issues)
- [ ] Findings suggest systemic dysfunction beyond process improvement
- [ ] Cannot determine whether previous retro actions were completed
- [ ] Incident under review is still ongoing

Escalate as: `{"status": "escalated", "reason": "...", "context": "...", "recommendation": "..."}`
## Success Criteria
- [ ] Previous retro actions reviewed with status (done/in-progress/dropped)
- [ ] All findings cite specific artifacts, metrics, or events
- [ ] No findings assign blame to individuals
- [ ] 3-5 action items with owner role, deadline, success metric
- [ ] Start/Stop/Continue categories all represented
- [ ] Output matches the JSON format above
- [ ] No escalation triggers hit (or all reported)
