retro v1.4.0A

Immutable. This exact content never changes and is served at /api/v1/blob/04526dae9a1f9066.

---
name: retro
version: 1.4.0
description: >
  Facilitates a structured GTM retrospective for cross-functional squads, anchored to OKRs
  and launch outcomes, that ends in root causes and decisions rather than venting. Use for
  post-launch reviews, GTM cycle debriefs, and sprint retrospectives where you need to fix
  what broke structurally before the next cycle.
metadata:
  author: Stefanos Karakasis
  context: brain-dependent
  quality_gate: true
last_updated: 2026-08-24
---

# retro — GTM Retrospective Engine for PMMs

Runs a structured retrospective for cross-functional squads that produces OKR-linked
decisions. Not a feelings circle. A diagnostic system.

---

## Trigger

- **When:** Post-launch review, GTM cycle debrief, sprint retrospective with a PMM lens, or any cross-functional session where decisions are needed, not just discussion.
- **Not for:** Pre-launch risk analysis → use `pre-mortem`. OKR setting for the next quarter → use `pmm-okrs`. Campaign briefing after a retro surfaces a messaging gap → use `gaccs-brief`. Competitive root cause analysis → no dedicated skill yet.
- **Example prompts:**
  - "Run a retro on our Q2 product launch"
  - "We missed our pipeline KR — let's debrief"
  - "What went wrong with the enterprise campaign?"
  - "Facilitate our post-launch review for the analytics dashboard"
  - "Our last sprint ended badly — help us figure out why"

---

## Inputs

- **Args:** Cycle name or launch name (required). Free format — one sentence minimum.
- **Defaults:** If no cycle named, run intake before proceeding. Never generate a retro output without a named cycle and at least one OKR to anchor to.
- **Context keys:**
  - `/foundation/brain.md` — optional but recommended. Load Section 2 (ICP), Section 3 (Alternatives & Positioning) and Section 7 (Strategy: priorities, launches with tier, quarterly goals) silently if present.
  - `/context/meta-patterns.md` — optional; recurring patterns the user has logged from all skills.

---

## Connectors (Optional)

| Connector | What it adds |
|---|---|
| `~~project tracker` | Launch tasks and outcomes |
| `~~knowledge base` | Launch docs and OKRs |
| `~~team chat` | Launch threads |
| `~~calendar` | Retro scheduling and attendees |

> **No connectors?** Paste the material and I'll work from that. The output has the same shape.
> Pulled facts are drafts: each is tagged with category, tool and date, and nothing is written until you confirm.

---

## Pre-flight

Before anything else, check `/foundation/brain.md`.

**If it exists — load silently. Extract:**
- Section 2 (ICP Definition) → shapes which failure modes are highest-stakes
- Section 3 (Alternatives & Positioning) → was the positioning coherent with this launch? Source of truth for diagnosis.
- Section 5 (Market Context) → which market forces was this initiative riding on? Root causes shift by context.
- Section 6 (Proof Points Registry) → what proof was this launch meant to generate or rely on?

**Confidence awareness:** If Section 3 (Alternatives & Positioning) or Section 2 (ICP Definition) is 🔴 Placeholder, flag before proceeding:
> "⚠️ Positioning is marked Placeholder in your brain. This retro may surface
> symptoms rather than root causes — update the brain first for sharper diagnosis."

**If missing:** Proceed. Surface once, non-blocking:
> "No brain found. Run `product-marketing-context` to make root cause
> diagnosis significantly sharper. Continuing."

If `/context/meta-patterns.md` exists in the user's workspace, check it for guardrails
from prior retros they've logged there. If a pattern applies, surface it before intake:
> "🔁 I've seen [pattern] in prior retros you've logged. Did this show up again here?"

If that file doesn't exist, skip silently — it isn't required for the skill to run.

---

## Steps
### Step 1: Run Intake
Ask in one message. Never generate before OKRs are confirmed.
> "Before I run the retro, three things I need:
>
> 1. **What cycle are we reviewing?** (Sprint / launch name / campaign name + dates)
> 2. **What were we trying to achieve?** (OKR + specific KRs this initiative was meant to move)
> 3. **What inputs do you have?** (Launch metrics, win/loss data, stakeholder feedback — paste or describe what's available)"
If OKRs are not provided: stop and ask specifically. A retro without OKR anchoring is a venting session with a timer.
Confirm before proceeding:
> "Got it. Reviewing [Cycle Name] against [OKR]. Starting with outcome anchor."
---
### Step 2: Set Outcome Anchor
Establish the evidence base before collecting any feedback.
````
GTM Cycle / Sprint: [Name or number]
Period: [Start → End]
Primary OKR: [Objective]
Key Results targeted: [KR1 / KR2 / KR3]
Outcome: [Achieved / Partially achieved / Missed] — [metric with number]
Launch tier assigned: [T1 / T2 / T3 / T4]
Days since launch: [N]
Market response: [Better / As expected / Worse than predicted]
````
Ask one calibrating question: "Did the market respond the way we expected? Yes or no."
---
### Step 3: Select Format
Infer from context or ask.
| Format | Use Case | Focus |
|--------|----------|-------|
| **A — GTM Health Check** | Launch cycles, campaign sprints | Assess market impact |
| **B — OKR Gap Analysis** | When KRs were missed | Trace root cause to KR failure |
| **C — Cross-Functional Tension Map** | When collaboration broke down | Name the structural cause |
---
### Step 4: Collect and Structure Feedback
Group feedback into 3–5 themes. Tag each: GTM impact or Process friction. Rank by OKR relevance.

If `/context/meta-patterns.md` exists and a theme matches a pattern logged there, flag it:
> "⚠️ This theme has appeared in prior retros you've logged. See [pattern]."

**Important:** If "communication" appears as a theme, push for the structural root cause. Communication is never the real cause — it's a symptom.
---
### Step 5: Root Cause Diagnosis
For each top theme, build a diagnostic chain:
| Theme | Surface observation | One level deeper | Structural root cause |
|-------|-------------------|-----------------|----------------------|
| [Theme] | [What people said] | [What it means] | [Process/RACI/timing/brief quality] |
**PMM-specific root causes to check:**
- Late brief (positioning or messaging locked too close to launch)
- Untested positioning (claim validation gap)
- Tier mismatch (assigned T2, but market signals said T1 or T3)
- Sales misalignment (enablement gap or comp misalignment)
- Competitive blind spot (missed alternative or competitor move)
- Post-sales prep gap (support docs / training not ready)
- KR design failure (metric didn't measure what mattered)
- Champion alignment failure (champion wasn't aligned before go-live)

**Always run tier assessment:**
| | Assigned | Warranted | Gap |
|---|----------|-----------|-----|
| Launch tier | [T?] | [T?] | [Over / Under / Correct] |
---
### Step 6: Correlate with Pre-Mortem Predictions

If the user ran a `pre-mortem` before this launch and has it available, compare
predicted risks to what actually materialized:
- Which Tiger risks came true?
- Which risks didn't materialize (and why)?
- Which risks did we miss?

Surface to user:
> "Pre-mortem accuracy check: We predicted 8 risks, 5 materialized, 2 we missed, 1 didn't happen."

If no pre-mortem exists for this launch, skip this step — recommend running one for the next cycle instead.

---
### Step 7: Action Items
Max 3. Each must link to a KR or go to backlog.
| Priority | Action | KR | Owner | Deadline | Success Metric |
|----------|--------|----|----|----------|--------|
| 1 | [Structural change] | [KR ref] | [Single owner] | [Date] | [Measurable] |
**Rules:**
- Single owner only. "Improve communication" is not an action item.
- Carry-over items from the previous retro take priority, if the user has one to reference. If carry-over isn't done, ask why first.
- Every action must be structural (process, RACI, artifact, timing) — not aspirational.
---
### Step 8: Surface Learnings

If the retro surfaces a pattern worth remembering — a timeline assumption, a
recurring gap, a new anti-ICP signal — name it explicitly and ask the user if and
where they want it saved (their own notes, a brain-adjacent doc, or
`/context/meta-patterns.md` if they maintain one). This skill does not write to
any file on its own.

---
### Step 9: Deliver Output
Deliver the retro summary (see Outputs section).
---
### Step 10: Learning Close

End every completed session by appending one entry to `/context/skill-sessions.md`,
in the format defined in `product-marketing-context/.claude-plugin/skill-sessions-format.md`
(Type A — execution session):

````yaml
type: execution
skill: retro
session_date: [YYYY-MM-DD]
pattern: [one falsifiable statement about what happened this session, or "none"]
source: [surprised / wrong / missing / N/A]
````

Write this row directly — do not ask the user for permission. This is a
separate, mechanical row from Step 8's Learnings to Remember, which is a
user-facing summary of what to carry forward, not a file write. If nothing
notable happened this session, still write the row with `pattern: none`.

---
## Outputs
- **Chat output format:** Retro summary in the template below. Markdown formatted for copy-paste into Notion or Google Docs.
- **Files written:** `/context/skill-sessions.md` — one appended row per
  session, per Step 10.
- **External side effects:** None beyond the session log above.

````markdown
## GTM Retrospective — [Cycle Name] — [Date]
**Format used:** [A / B / C]

### Outcome Anchor
- **OKR:** [Objective] | **KRs:** [list] | **Result:** [metric] | **Tier assigned / warranted:** [T2 / T2]

### Pre-Mortem Correlation (if applicable)
- **Predicted 8 risks, 5 materialized, 2 missed, 1 avoided**
- Tiger risks that materialized: [list]
- Tiger risks that didn't: [list]
- Pre-mortem accuracy: [67%]

### Top Themes
| # | Theme | Type | Root cause | Recurring? |
|---|---|---|---|---|
| 1 | | | | |

### Action Items
| # | Action | KR | Owner | By | Metric |
|---|---|---|---|---|---|
| 1 | | | | | |

### Learnings to Remember
- [Pattern worth carrying forward — ask user where to save it, if anywhere]

### Carry-over from Last Retro
- [Previous action] — [Done / In Progress / Not Started]

### One PMM Takeaway
[Single sentence: most important structural change before next cycle]
````
---
## Verification
- Guardrails checked before intake, if `/context/meta-patterns.md` exists.
- Cycle name and at least one OKR confirmed before output generated.
- Retro format (A/B/C) selected and stated.
- Every theme has a named structural root cause — not "communication."
- Every action item links to a KR or is explicitly backlogged.
- Action items have single owner, deadline, and measurable success metric.
- Tier assessment run and gap stated.
- Pre-mortem correlation checked if a prior pre-mortem is available.
- Learnings surfaced with the user, not written anywhere without asking.
- Session logged to `/context/skill-sessions.md` (Step 10), separate from Step 8's user-facing learnings.
---
## Do Not Use For
- **pre-mortem** — for risk analysis before a launch, not after. Run this skill on a completed cycle; run `pre-mortem` on the next planned one.
- **pmm-okrs** — if the retro surfaces KR design failure, use `pmm-okrs` to rebuild the measurement plan. Don't rebuild OKRs inside a retro session.
- **gaccs-brief** — if the retro surfaces a campaign or messaging failure, use `gaccs-brief` to rebuild the brief for the next cycle.
---
## Operating Rules
- **OKR anchoring is mandatory.** A retro without OKRs is not a retro — it's a venting session. Stop and get OKRs before proceeding.
- **Root causes must be structural.** "Communication" is never a root cause. Always push one level deeper to the process, RACI gap, or brief quality failure.
- **Max 3 action items.** More than 3 means priorities aren't clear. Force the choice.
- **Single owner only.** Shared ownership = no ownership. Name one person.
- **Carry-over first.** If prior retro items aren't done, address that before adding new ones. Track why the prior action stalled.
- **Tier assessment on every retro.** Always compare tier assigned vs. tier warranted. Tier mismatch is the most common under-diagnosed root cause.
- **Pre-mortem correlation when available.** Compare predicted risks to actual outcomes if the user has a pre-mortem for this launch.
- **Anti-patterns get named in the room.** Retrospective theatre, "Eng was too slow", "market wasn't ready" — call them out explicitly when they surface. These are red flags for deeper issues.
- **Quality gate runs before final delivery.** Minimum 12/15 on the criteria. Below that: revise before presenting as complete.
---
## Related Skills

Cross-reference these when a retro surfaces issues that belong elsewhere:

- **product-marketing-context** → source of ICP, positioning, and brain context
- **pre-mortem** → if the next launch is already planned → run risk analysis before it ships
- **gaccs-brief** → if retro surfaces campaign or messaging failure → rebuild the brief
- **pmm-okrs** → if KR design or success metric ambiguity drove the miss → route here
- **prioritization-frameworks** → If tier mismatch is identified, route to `prioritization-frameworks` for rescoring.

---

## Quality Gate
Runs before final delivery. Score each criterion 1–3. Minimum 12/15 to pass.
| Criterion | Standard | Score (1–3) |
|---|---|---|
| Guardrails surfaced | Patterns checked if `/context/meta-patterns.md` exists | |
| OKR anchor | Every theme and action traces to a KR or is explicitly backlogged | |
| Root cause depth | No theme stops at "communication" — structural cause named for each | |
| Action item quality | Max 3, single owner, measurable metric, OKR-linked | |
| Tier diagnosis | Launch tier assessed and compared to warranted | |
| Learning Close ran | `/context/skill-sessions.md` has a new row for this session | |

**On failure:** Identify which criterion failed, revise, do not present as final.