session-retro

To extract lessons learned from a session transcript, analyze high-value signals such as failed tool calls, human corrections, and escalations to identify specific friction points. This process transforms repeated mistakes into actionable process improvements.

The best way to categorize retrospective insights is to sort them into four specific outcomes: rules, sensors, issues, and eval-cases. This action routing separates insights into prevention rules, detection checks, deferred problems, and reusable evaluation cases.

You should run a retrospective analysis at the end of shipping, release, or issue-driven work sessions. Applying it at these milestones captures what needs to be documented, tested, deferred, or preserved before context is lost.

To create guardrails against repeated tool failures, analyze the failure signals from your transcript and generate specific prevention rules and detection checks. These guardrails are categorized as rules and sensors to actively reduce repeat failures.

Yes, you can generate reusable evaluation cases from session failures by extracting the specific scenarios where tools failed or humans corrected the workflow. These events are routed into eval-case recommendations for future testing.

Session retrospective analysis works without external dependencies by processing the transcript directly to identify failures and corrections. It relies solely on the session transcript content to generate follow-up proposals and guardrails.