Retro

---
name: retro
description: >
  Activate for: retrospective, retro, post-mortem, post launch review,
  feature review, what went well, what didn't go well, lessons learned,
  sprint retrospective, product review, launch review, did it work,
  measure impact, feature retrospective, post-ship review, outcome review,
  product retro, evaluate feature success.
  NOT for: metrics dashboards (use official /metrics-review), stakeholder
  updates (use official /stakeholder-update), sprint planning
  (use official /sprint-planning).
license: Apache-2.0
argument-hint: "<feature name> retrospective"
metadata:
  author: Panaversity
  version: "1.0"
  plugin-commands: "/retro"
---

## CONTEXT LOADING

Before running a retro, load `product.local.md` for product context,
quality standards, and PM process standards. If not configured, ask the
user for product context and the feature being reviewed.

## RETROSPECTIVE WORKFLOW

### The Four Retro Questions

A useful product retro answers exactly four questions:

  Q1: DID IT SOLVE THE PROBLEM?
    Was the PM right about the user need?
    Did the feature change what it was supposed to change?

  Q2: DID WE BUILD IT AS INTENDED?
    Was the spec good enough? Did engineering deliver what was specified?
    Were there scope changes, quality issues, or delivery delays?

  Q3: WERE THE METRICS RIGHT?
    Were the success metrics we defined measuring the right things?
    Did we have a failure threshold, and were we honest about it?

  Q4: WHAT WOULD WE DO DIFFERENTLY?
    Not "what went wrong" -- but "what specific process change would
    we make if we started this feature again today?"

### Data Required Before Running a Retro

OUTCOME DATA (4-12 weeks post-launch):
  - Adoption: % of target users who have used the feature at least once
  - Engagement: how often? for how long? (if applicable)
  - Support impact: did support tickets about this area increase or decrease?
  - NPS impact: has there been movement in relevant NPS questions?
  - Business metric: did the primary success metric move?

DELIVERY DATA:
  - On time or late? If late: by how long?
  - Were there scope changes during development? What was added or cut?
  - Were there significant spec ambiguity issues flagged by engineering?

TEAM DATA (optional but valuable):
  - Did engineering flag any spec quality issues?
  - Did design flag any requirement gaps during design review?
  - Did CS/Support flag anything unexpected post-launch?

### Retro Output Format

```
PRODUCT RETROSPECTIVE: [Feature name]
Shipped: [Date] | Retro date: [Date] | PM: [Name]
================================================================

Q1: DID IT SOLVE THE PROBLEM?

Original problem:   [From the spec -- what were we trying to solve?]
Target outcome:     [From the spec -- what did we say success looked like?]

Evidence:
[PASS/WARN/FAIL] [Metric]: [actual result] vs. [target]
[PASS/WARN/FAIL] [Metric]: [actual result] vs. [target]

Verdict: [SOLVED / PARTIALLY SOLVED / NOT SOLVED / TOO EARLY TO TELL]
Summary: [2-3 sentences: what the data shows about whether the
          feature delivered on its intent]

Q2: DID WE BUILD IT AS INTENDED?

[PASS/WARN/FAIL] Delivered on time: [On time / [N] weeks late -- reason]
[PASS/WARN/FAIL] Spec quality:     [No major ambiguity / [Issue reported]]
[PASS/WARN/FAIL] Scope maintained: [No changes / Changes: describe]
[PASS/WARN/FAIL] Quality (bugs):   [Bug rate in first 30 days]
[PASS/WARN/FAIL] ACs met:          [All ACs verified / Outstanding: list]

Q3: WERE THE METRICS RIGHT?

For each success metric defined in the spec/PRD:
- Was it measurable? (Could we actually get the data?)
- Was it sensitive? (Did it move in response to the feature?)
- Was it the right thing to measure? (Did it reflect user value?)
- Did we have a failure threshold? Did we use it?

Metric quality rating: [HIGH / MEDIUM / LOW]
Learning: [What we should measure differently next time]

Q4: WHAT WOULD WE DO DIFFERENTLY?

Process improvement [N]:
  What happened:  [Specific -- not "better communication"]
  What to change: [Specific rule or step to add/change]
  How to apply:   [On the next feature: [specific action]]

FOLLOW-ON ACTIONS (from retro findings)
[N]. [Action] -- [Owner] -- [Due date]

PRODUCT.LOCAL.MD UPDATES RECOMMENDED
[Any quality rules to add to the configuration based on this retro]
================================================================
```

### Process Improvement Format

Rule: Every "what went wrong" must be converted into a specific,
testable process change -- not a vague intention.

  WEAK:  "Write better specs"
  STRONG: "Every AC must be independently testable.
           If an AC contains 'and', split it before REVIEW status."

  WEAK:  "Communicate better with engineering"
  STRONG: "Engineering lead must confirm architecture notes in PRD
           before the PRD moves to REVIEW status."

  WEAK:  "Define success metrics earlier"
  STRONG: "Primary metric and failure threshold must be in the spec
           before it enters sprint planning. No spec without metrics."

## COMPLEMENTARY WORKFLOWS

This skill handles product retrospectives. For related PM workflows:
- Reviewing metrics that inform the retro: use official `/metrics-review`
- Communicating retro findings to stakeholders: use official `/stakeholder-update`
- Updating the roadmap based on retro learnings: use official `/roadmap-update`

## NEVER DO THESE

- NEVER run a retro without outcome data -- opinions without data
  produce blame, not learning
- NEVER produce a retro that only documents what went wrong --
  what went well is equally important (protect what works)
- NEVER produce a vague process improvement ("communicate better")
  -- convert every improvement into a specific, enforceable rule
- NEVER skip the metrics quality section -- bad metrics are as
  dangerous as no metrics; they create false confidence
- NEVER close a retro without at least one product.local.md
  update -- if nothing changes, the retro was a waste of time

ALL OUTPUTS REQUIRE REVIEW BY THE PM AND ENGINEERING LEAD.