---
name: retro
description: Conduct an end-of-session retrospective. Reviews what went well, what went wrong, how to improve collaboration, and saves lessons to memory.
---

# Skill: retro

Conduct an end-of-session retrospective. TRIGGER when the user invokes /retro or asks to review how the session went.

## Instructions

Walk through each section below with the user. Be honest and specific — cite actual moments from the session, not generalities. Use direct language.

### 1. What went wrong?

Identify things that didn't work well:
- Misunderstandings or miscommunications
- Wasted effort (wrong approaches, unnecessary changes, rabbit holes)
- Bugs introduced, regressions, or things that broke
- Times I overcomplicated something or under-delivered

### 2. What went right?

Identify things that worked well:
- Efficient solutions, clean implementations
- Good collaboration moments
- Problems solved on the first try

### 3. What should we keep doing?

Patterns or practices worth repeating in future sessions.

### 4. What should we explicitly avoid?

Anti-patterns to watch out for. Be concrete — name the specific behavior, not a vague principle.

### 5. How can the user interact with me better?

This is critical. Hold the user accountable. Evaluate their instructions and flag:
- Ambiguous or underspecified requests that led to wrong outcomes
- Missing context that would have saved time
- Cases where earlier clarification would have prevented rework
- Suggestions for how to phrase requests more effectively

Be direct. The user has explicitly asked to be held accountable for poor instructions. Do not soften feedback — give actionable, specific suggestions.

### 6. Configuration health check

Do a web search for current Claude Code best practices and configuration options. Look for:
- New features or configuration mechanisms that have been added (rules, hooks, agents, plugins, .claudeignore, etc.)
- Common misconfigurations or gaps in typical setups
- Improvements to how memory, CLAUDE.md, and hooks work together

Report any gaps or opportunities specific to this project's current setup. Be concrete — name specific files or settings to add/change, not general advice.

### 7. Lessons to remember

For each lesson worth saving, classify it into one of three buckets before writing:

- **Project-specific** — tied to this codebase's conventions, stack, or tooling (e.g. `ENV` must be `"prod"`, just module path behaviour). Save to the project memory directory.
- **Language-specific** — a habit that applies to all projects in a given language (e.g. Python packaging conventions, test mirroring). Save to `~/.claude/rules/<language>.md`, creating the file if it doesn't exist. If the current project's CLAUDE.md doesn't already import that rules file, add `@~/.claude/rules/<language>.md` at the top.
- **Universal** — applies regardless of language or project (e.g. collaboration habits, tool-use patterns). Save to `~/.claude/CLAUDE.md` under a `## General Habits` section. Keep this list short — only rules that would genuinely apply everywhere.

Present the classification to the user for each lesson and ask for confirmation before writing anything.