retro

Captures post-release learnings and decides whether product assumptions need revision.

Updated Aug 4, 2026
One-click install
npx skills add https://github.com/rombel00/game-processes --skill retro-rombel00
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: retro
Source: https://github.com/rombel00/game-processes/tree/main/plugins/product-definition/skills/retro
Command: npx skills add https://github.com/rombel00/game-processes --skill retro-rombel00

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? After a release or milestone, teams often skip reflection or write reports nobody reads, so disproven assumptions silently persist into the next cycle. This Skill turns the gap between what was promised (task_spec acceptance criteria) and what live verification actually showed (test_report) into a structured learnings record that feeds back into the brief or discovery phase. ## Core Features & Use Cases - Promised vs. observed comparison: Contrasts task_spec section 9 acceptance criteria with test_report results to surface the most valuable signal of the cycle. - Fact vs. interpretation separation: Records observed facts and hypotheses as distinct entries so interpretations are treated as inputs for the next cycle, not conclusions. - Assumption audit across artifacts: Walks brief, lean_canvas, market, roadmap, and story_map with yes/no verdicts, and flags downstream documents in status.md when a brief revision is recommended. - Use Case: After a playtest shows 3 of 10 players failed onboarding step 2, append a dated learnings entry, mark the story_map readiness criterion as disproven, and recommend returning to discovery with the specific open question logged for the owner. ## Quick Start Run a retro on the latest release using the task_spec and test_report, and append the findings to the learnings artifact.

Frequently Asked Questions about retro

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run a product retrospective after a release?▼

Gather the task_spec acceptance criteria and the test_report from live verification, then record what was promised versus what was observed. Separate facts from interpretations, audit each upstream document for changed assumptions, and append a dated entry to the learnings artifact.

What is the difference between facts and interpretations in a retro?▼

A fact is a direct observation, such as "3 of 10 users did not pass onboarding step 2." An interpretation is a hypothesis like "the onboarding is too long." Record both separately so interpretations are treated as inputs for the next cycle, not settled conclusions.

Can I run a retro without a task_spec?▼

Yes. When the work went straight from brief to code, use direct observation as the fact source: how the result felt in use, what surprised you, and whether it matches the brief. This is the cheapest and often most useful retro.

What happens when a retro recommends changing the brief?▼

Add a line to the Open Questions section of status.md noting that brief was proposed for update and listing which downstream documents (story_map, open task_specs) have not been revised. The orchestrator does not detect staleness, so this manual flag is the only signal.

When should a retro trigger a return to discovery?▼

When any assumption audit answers yes: the problem or user turned out different, the riskiest lean canvas assumption failed, the competitive picture changed, the roadmap order no longer makes sense, or a playtest disproved a readiness criterion. One yes is a trigger, not a minor edit.