retrolisted

# /retro — session postmortem & self-improvement Analyze **this session's transcript** and turn its friction into durable improvements. Do NOT write any files until the user approves the proposal. ## Timing — when to self-trigger A retro belongs at the **end** of a session. This skill is model-invocable so it can catch rough sessions the user forgot to review — but do not let it derail active work: - **Mid-task:** if you notice a rough stretch while work is still in progress, do **not** launch a full retro. Finish the task first, then briefly offer one: *"This was a bumpy stretch — want a quick retro to capture the lessons?"* - **Session wrap-up / user signals done:** proactively offer the retro when there was real friction (repeated failures, rework, multiple corrections) and none has run yet. - **User asks explicitly:** run it now. Because retro only *proposes* changes and never writes without approval, offering is always safe — the cost of a mistimed offer is one declined suggestion. ## 1. Friction report Scan the session and bucket what went wrong. ### Execution friction - **Low-quality output** — wrong/incomplete results, rework, claims made without verification. - **Slowness / looping** — wasted time, redone work, the same approach retried without a success criterion. - **Repeated mistakes** — anything that went wrong more than once. ### Orchestration friction These are the failures that only show up in multi-agent work, and they are invisible unless you look