retro

# Retro Use completed work as evidence for improving the AI engineering environment. A retro evaluates the workflow, not the person. Do not turn one unusual failure into a permanent global rule without evidence that the rule would help future work. ## Process ### 1. Read the evidence Review the relevant: - conversation or agent session; - issue or spec; - commits and diff; - verification results; - review findings; - failures and rework. When evaluating reusable configuration, record the artifact and the real task where it was used, plus the observed result or friction. If it has not been used in a real task, say it remains untested; passing a validator is not usage evidence. ### 2. Identify friction Look for concrete problems in: #### Context - information was hard to find; - instructions were duplicated; - source-of-truth conflicts occurred; - important context was loaded too late; - too much irrelevant context was always loaded. #### Skills - a repeatable workflow was performed manually; - a skill produced ambiguous behavior; - a skill duplicated another skill; - completion criteria were too weak. #### Rules - an important judgment rule was missing; - an existing rule caused unnecessary friction; - a rule belongs in a project instead of globally. #### Automated checks - an error could have been caught deterministically; - an existing check was not being run; - CI, linting, typing, tests, or validation had a gap. Prefer automation over prose rules for mechanical failures. #### Tools - repeated expensive or unnecessary tool usage; - missing access caused guesswork; - a simpler tool would have produced better evidence. #### Workflow - unnecessary approvals; - excessive context switching; - poor task boundaries; - weak handoffs; - implementation began before decisions were ready. ### 3. Propose improvements For each meaningful finding include: - evidence; - what went wrong; - proposed change; - where the change belongs; - expected benefit; - risk or tradeoff. Possible destinations: - project instructions; - global rule; - skill; - agent; - template; - deterministic check; - no change. ### 4. Classify the result Use: - `testing` for a new idea that needs evidence; - `accepted` when the user explicitly adopts it; - `rejected` when the user explicitly rejects it; - `default` when the user explicitly promotes it to normal workflow; - `replaced` when a newer approach supersedes it. A retro recommendation is not automatically adopted. ## Rules - Evidence before policy. - Do not create permanent rules from stylistic preference alone. - Mechanical problems should usually become deterministic checks. - Avoid duplicating instructions across files. - Keep always-loaded context small. - Distinguish one-off mistakes from recurring workflow problems. - The user decides whether a proposed change becomes part of the workflow. ## Completion A retro is complete when it clearly states: - what worked; - what caused friction; - what should change; - where the change belongs; - what should remain unchanged; - which recommendations still require testing.