/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