Hs Retro

GTM Retrospective Engine for PMMs

Runs a structured retrospective for cross-functional squads that produces OKR-linked decisions — and gets smarter every session. 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 hs-pre-mortem. OKR setting for the next quarter → use hs-brainstorm-okrs. Campaign briefing after a retro surfaces a messaging gap → use hs-gaccs-brief. Competitive root cause analysis → use hs-competitive-battlecard.
• 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 ICP, Positioning, Revenue Levers, GTM Motion, Launch Tier Definitions silently if present.
• /context/meta-patterns.md — optional; recurring patterns from all skills (guardrail prompts + cross-skill signals)
• knowledge/retro-patterns/rules.md — apply all active rules by default, silently.
• knowledge/retro-patterns/hypotheses.md — note any open hypothesis testable today.
• decisions/ — check for prior structural decisions before making new ones.
• sessions/ — surface carry-over action items from the most recent session file.

Brain contract: Reads: Section 2 (ICP), Section 3 (Positioning), Section 5 (Revenue), Section 7 (Launch history). Writes: /context/skill-sessions.md, /foundation/brain.md Section 7 (learnings), /context/knowledge/retros/. ---

Pre-flight

• Load guardrails first: Check /context/meta-patterns.md for recurring patterns from prior launches. If pattern matches (e.g., "champion alignment was gap in 2+ retros"), surface guardrail prompt before Step 1.
• Load /foundation/brain.md silently if present. Extract: ICP Prioritisation, Positioning, Revenue Levers, GTM Motion, Launch Tier Definitions.
• If Positioning or ICP is 🔴 Placeholder, flag before proceeding:

> "⚠️ Positioning is marked Placeholder. This retro may surface symptoms rather than root causes — update context first for sharper diagnosis."

• If brain missing: proceed, surface once:

> "No brain found. Run hs-product-marketing-context for sharper root cause diagnosis. Continuing."

• Load knowledge/retro-patterns/rules.md — apply silently.
• Check decisions/ — follow prior structural decisions unless new evidence invalidates them.
• Check sessions/ — surface carry-over action items before intake.
• If knowledge files don't exist: create folder structure silently. System builds from session one.

---

Steps

Step 0: Surface Guardrails (NEW)

Before intake, check for patterns:

If /context/meta-patterns.md exists and contains retro patterns:

🔁 PATTERN DETECTED FROM PRIOR LAUNCHES

I've seen [specific pattern] in [N] prior retros.
Example: "Champion alignment was a gap in retros #1 and #2", "Post-sales prep consistently underestimated", "Competitive response faster than predicted"

Quick question: Did [specific pattern] show up in this launch too?
- If YES → we'll flag it as a confirmed pattern + update guardrails
- If NO → we'll watch for other gaps

This helps the system learn what to expect in future launches.

Common guardrail patterns to surface:

• "Champion alignment gaps in 2+ retros" → "Was champion alignment an issue here too?"
• "Post-sales prep underestimation in 2+ retros" → "Did support docs/training get completed on time?"
• "Competitive response faster than predicted (3+ retros)" → "Did a competitor respond faster than you expected?"
• "Tier mismatch (over-assigned in 2 retros)" → "Were you over-investing GTM weight for the actual market response?"

If patterns apply, ask guardrail question. User can skip, but they've been warned.

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. Cross-reference against knowledge/retro-patterns/rules.md — flag recurring patterns: > "⚠️ This theme has appeared in prior retros. See [Rule ID]."

Check /context/meta-patterns.md for cross-skill signals: > "💡 Cross-skill signal: 'Post-sales prep' appeared in 2 PDRs + 2 retros. This retro confirms it. Pattern is now solid."

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 pre-mortem exists from before this launch:

1. Load the pre-mortem file (check /context/knowledge/risks/ for matching launch)
2. Compare predicted risks to what actually materialized:

• Which Tiger risks came true?
• Which risks didn't materialize (and why)?
• Which risks did we miss?

1. Log correlation to /context/skill-sessions.md (see Step 8)
2. Surface to user:

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

This feeds meta-synthesis: Retro + pre-mortem correlation teaches the system about prediction accuracy.

---

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 carry-over isn't done, ask why first.
• Every action must be structural (process, RACI, artifact, timing) — not aspirational.

---

Step 8: Propose Brain & Context Updates (NEW)

If retro surfaces learnings to encode:

Learnings to update brain Section 7 (Meta-Learnings):

• "Timeline assumption: +48 hours for champion alignment (confirmed 2x)"
• "Competitive response timing: 24-48 hours (not 1 week)"
• "Post-sales prep must be done 7 days pre-launch (confirmed 2x)"
• "Sales adoption blockers: [specific pattern]"

Learnings to update anti-ICP (brain Section 2):

• "Long procurement cycles (60+ days) = deal-killer" (if discovered)
• "Requires legal review" (if discovered)

Surface explicitly with approval gates: > "Should we update brain Section 7 with: 'Timeline assumption: +48 hours for champion alignment'? > This appeared in retro #1 and #2, now confirmed."

---

Step 9: Post-Session Logging (NEW)

After every session, log structured data to /context/skill-sessions.md:

skill: retro
session_date: 2026-06-21
launch_name: "SSO Integration Launch"
launch_tier: "T2"
launch_date: 2026-06-15
retro_date: 2026-06-21
days_post_launch: 6
pre_mortem_existed: true
pre_mortem_date: 2026-05-15
okr_result:
  objective: "Accelerate enterprise adoption"
  krs_achieved: 2
  krs_partial: 1
  krs_missed: 0
  achievement_rate: 1.0
wins_categories:
  positioning: "Anchor resonated with dev personas (70% CTR)"
  sales_execution: "Champion adoption: 8/10 early accounts in first week"
  speed: "Launch prepped in 2 weeks (ahead of 3-week plan)"
gaps_categories:
  champion_alignment: "IT integration team not aligned until day 3 (48-hour delay)"
  competitive_response: "Competitor launched same day, lost positioning differentiation"
  post_sales_prep: "Onboarding docs not ready, support flooded day 1-2"
risks_materialized:
  - "Champion alignment" # from pre-mortem
  - "Post-sales prep"
risks_did_not_materialize:
  - "Sales adoption hesitation"
pre_mortem_accuracy: 0.67
tier_assigned: "T2"
tier_warranted: "T2"
tier_assessment: "Correct"
market_response: "Better than predicted"
output_path: "/context/knowledge/retros/retro-20260621-sso-launch.md"
guardrails_triggered:
  - "Champion alignment gap (48 hours). This is the 2nd launch with this issue. Recommendation: add 'Champion & IT alignment' to all future launch checklists."
  - "Post-sales prep gaps confirmed again. Add to pre-mortem: 'Are support docs + training ready 1 week before launch?'"
  - "Pre-mortem accuracy: 67%. We're good at identifying risks but slow at predicting timing. Recommendation: add 'What day will this happen?' to pre-mortem risk definition."
brain_updates_proposed:
  - "Section 7: Timeline assumption +48 hours for champion alignment"
  - "Section 7: Post-sales prep must be done 7 days pre-launch"
  - "Section 7: Competitive response timing is 24-48 hours (not 1 week)"

This feeds into meta-synthesis skill (monthly) which detects patterns across all retros and updates brain + /context/meta-patterns.md.

---

Step 10: Deliver Output and Run Self-Improvement

Deliver the retro summary (see Outputs section). Then run the self-improvement loop: write session file → update knowledge base → log decisions → run quality gate → propose brain updates. ---

Outputs

• Files written:
• /context/skill-sessions.md — row appended with session metadata and guardrails (NEW)
• sessions/YYYY-MM-DD-[cycle].md — session file after every retro.
• knowledge/retro-patterns/hypotheses.md — new patterns observed 1–2 times.
• knowledge/retro-patterns/rules.md — patterns confirmed 3+ times (approval required).
• decisions/YYYY-MM-DD-[topic].md — structural decisions made during the session.
• /foundation/brain.md Section 7 — updated with learnings (if approved)
• /foundation/brain.md Section 2 — updated with anti-ICP signals (if discovered)

• Chat output format: Retro summary in the template below. Markdown formatted for copy-paste into Notion or Google Docs.
• External side effects: None beyond context writes.

## 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 (NEW)
- **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? | Cross-skill signal? |
|---|---|---|---|---|---|
| 1 | | | | | |

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

### Brain Updates Proposed (NEW)
- **Section 7 (Meta-Learnings):** [Learnings to encode]
- **Section 2 (Anti-ICP):** [Anti-signals discovered, if any]
- **Status:** Awaiting approval

### 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 (Step 0) — patterns from prior launches surfaced.
• 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 and logged (if pre-mortem exists).
• Brain update proposals surfaced with approval gates.
• Session file written to sessions/.
• Data logged to /context/skill-sessions.md.
• Quality gate scored before output delivered as final.

---

Do Not Use For

• hs-pre-mortem — for risk analysis before a launch, not after. Run this skill on a completed cycle; run hs-pre-mortem on the next planned one.
• hs-brainstorm-okrs — if the retro surfaces KR design failure, use hs-brainstorm-okrs to rebuild the measurement plan. Don't rebuild OKRs inside a retro session.
• hs-gaccs-brief — if the retro surfaces a campaign or messaging failure, use hs-gaccs-brief to rebuild the brief for the next cycle.
• hs-competitive-battlecard — if competitive displacement is the root cause, route there for the battlecard work. Don't run competitive analysis inside a retro.

---

Operating Rules

• Guardrails first. Load /context/meta-patterns.md at pre-flight. Surface guardrail prompt if pattern matches this launch type.
• 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 is automatic. Compare pr

…

Source & license

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

• Author: stefanoskarakasis
• Source: stefanoskarakasis/Product-Marketing-Skills
• License: MIT
• Homepage: https://stefanoskarakasis.substack.com/

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