Retro Cairn

---
name: retro-cairn
description: Use when wrapping up a task or after fixing an error: list the mistakes that appeared and got fixed along the way (including ones a user corrected), attribute them, turn them into recurrence-preventing safeguards, and land each safeguard in the code it concerns.
---

# retro-cairn: process error -> safeguard

This repo's canonical name is `retro-cairn`, not `retro`: a personal-level skill of the same name takes precedence over a project-level one, so the repo cannot take over the name `retro` (the same reason as `pr-cairn`). After switching accounts or machines, cloning this repo makes it available without depending on personal skills.

Principle: a mistake that appeared during the process, even if fixed by the end, must be surfaced so the same kind gets stopped automatically next time. This applies to mistakes an agent makes itself and to mistakes made by the systems under management.

## When to trigger

- Before wrapping up a thread or task and preparing the report (no user reminder needed).
- After a test goes red then green, several rounds of CI fixes, a review rejection, a plan being turned down, a retry, a rollback, or being corrected by a user.

## Steps

1. List the errors: list every "appeared and got fixed" point, one sentence describing the symptom. Ones a user corrected always count.
2. Attribute: ask "why was it not stopped at the time", find the root cause (missing check, unclear rule, missing context, tool misuse).
3. Choose a safeguard on the correction ladder, the highest rung you can build now: codebase (the mistake becomes impossible to write), then static analysis (lint, compiler, CI), then rules and review rules, then skills, then a style guide only humans enforce. Write the reason when you stop below static analysis. Use the real mistake as a negative control for a new machine check: red before the fix, green after.
4. Record: the safeguard itself is the record. Name the mistake it stops in the PR that adds it. Do not write files under `docs/lessons/`; that directory is a frozen archive.
5. Recurrence: an existing safeguard that stopped the mistake before commit is an intercept; count it and stop. The same kind of mistake landing despite a safeguard is a recurrence: the current rung failed, so choose again from codebase.
6. Report: when wrapping up, summarize in one or two sentences how many process errors were caught and what safeguard each became.

## Boundaries

- Ask the user first before a safeguard that touches design decisions, protected paths, or changes intended behavior.
- Safeguards go through the normal PR flow (open PR; arm its merge only when pr-gate returns go with `mergedBy: 'auto-merge'`, otherwise it goes to ian; wrap up), not around review.
- Do not aim for "never again"; aim for "every mistake has a home and a useful safeguard".