/retro

Improve the next delivery from what actually happened. Do not invent lessons to fill a retrospective template.

When evidence shows a recurring activity, consider a scoped personal workflow proposal with an example, test, owner review and rollback. Do not rewrite or silently publish the generic router. See personalization and reusable workflows.

1. Establish the period/task/milestone and intended outcome. Read relevant task/spec, review reports, failed checks, session/run events and owner feedback. Label missing transcript/process evidence; source inspection cannot reconstruct an unobserved session.
2. Reconstruct a short timeline of consequential decisions, changes, failures and recovery. Separate symptoms from causes and self-reports from independent observations. Include what worked so it is not discarded accidentally.
3. Identify repeated or costly friction: unclear acceptance, missing context, stale docs, wrong execution scope, repeated retries, poor review evidence, unnecessary questions or instruction overload. Link each claim to an event/check/diff/FDK rather than attributing motives to people or models.
4. Propose the smallest change likely to help: a better brief field, a bounded check, a retrieval cue, an interface seam, a clarified decision or a scoped preference. State benefit, cost, owner and an observable next-run success measure. Do not respond to one failure with a universal hard rule.
5. Route outcomes correctly. A repair becomes TSK; a factual investigation RDT; a documentation proposal DOC; a quoted correction FDK; a durable preference/fact MEM. Sensitive learning remains proposed. A process suggestion does not itself authorize another model/provider, a Git action or an automation.
6. Save the retrospective as DOC with data.kind: "retro" and evidence links using the retro template. Retain superseded reasoning and rollback paths. Use actual record tools or initialized standalone storage; otherwise deliver a labelled draft.
7. On the next relevant task retrieve the accepted lesson and evaluate its effect. Report a failure of the proposed improvement honestly instead of repeatedly appending the same instruction.

Completion

End with observed outcome, what to keep, the most consequential friction and a small owned action list with verification. Separate proposed from accepted/applied changes. Do not bulk-mark tasks Done: a sweep can present evidence-backed completion candidates for owner confirmation.

Example: several sessions omitted native tool-use evidence. A useful improvement adds the actual workspace/tool observation to acceptance. “Be more careful” is neither a procedure nor a verifiable lesson.