retrospective

Reviews a development phase transcript and converts process lessons into durable rules.

Updated Jul 28, 2026
One-click install
npx skills add https://github.com/oleg-vasilyev/FoolProof --skill retrospective-oleg-vasilyev
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: retrospective
Source: https://github.com/oleg-vasilyev/FoolProof/tree/main/.claude/skills/retrospective
Command: npx skills add https://github.com/oleg-vasilyev/FoolProof --skill retrospective-oleg-vasilyev

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Development phases accumulate invisible waste — rework, repeated gate runs, subagents that cost more than they saved, and stale rules nobody deletes. This Skill audits how a stretch of work was actually carried out, using the session transcript as evidence, and turns each finding into a concrete rule change before the context is compacted away. ## Core Features & Use Cases - Six-question audit: Counts rework, repeated gate runs, subagent cost versus payoff, sequencing mistakes, redundant re-reading, and rules made obsolete by the phase. - Evidence-based answers: Requires numbers from the transcript rather than impressions, with none as an explicit valid answer per question. - Rule lifecycle management: Lands each lesson as a diff to the relevant skill or flow document, displaces an existing rule when budgets force it, and records removals in the commit's Retro: line. - Use Case: At the end of a development phase, run the retrospective to discover that a gate was re-run eight times where two would do, then encode that as a rule so the next phase avoids it. ## Quick Start Ask the assistant to run the retrospective gate on this session's transcript and report the six answers with counts before the context is compacted.

Frequently Asked Questions about retrospective

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

FAQPage Schema
How do I run a retrospective on a development phase?▼

Run it in the same conversation whose transcript is the evidence, at the end of the phase or before a visible compaction. Answer the six fixed questions with counts from the session, then land each lesson as a rule change in the same commit.

What questions does a development process retrospective ask?▼

It asks six: what was reworked, how many times each gate ran, whether subagents paid for themselves, whether sequencing caused conflicts, what was re-read unnecessarily, and which existing rules the phase made obsolete.

Why should a retrospective not run in a forked conversation?▼

A fork re-sends the entire transcript per call, which was measured as the costliest line of a phase for minimal output. The retrospective's subject is the transcript itself, so it must run where that transcript already exists in context.

When should a rule be deleted from project documentation?▼

Delete a rule when a machine check now enforces it, when its subject no longer exists in the repository, or when two rules share one cause and can merge. Never delete a rule merely because it has been quiet.

What are the limitations of transcript-based process audits?▼

The audit only sees what happened in the current session, so it cannot judge older backlog issues, which belong to a separate deep-checkup. Answers without counts are treated as guesses, so missing telemetry limits conclusions.