Engineering Retrospective
Review how the engineering system worked over a defined period. This is distinct from postmortem: it looks for recurring delivery and quality patterns even when no incident occurred. Keep the analysis blameless and resist turning activity volume into a productivity score.
Establish the Window and Evidence
- Resolve the repository, base branch, local timezone, and explicit period; default to the most recent seven complete days only when the user gave no window.
- Prefer a freshness-verified remote base when network access and authorization allow a fetch. Otherwise disclose the exact local ref and latest commit date.
- Collect available git history, merged pull requests, review cycles, test changes, CI outcomes, incidents, backlog movement, and release evidence. State which sources were unavailable.
- Normalize author aliases only when evidence supports the mapping. Do not infer performance, effort, or working hours from commit timestamps or line counts.
Analyze the System
Look for evidence-backed patterns in:
- delivered outcomes and work that remained unfinished;
- regressions, repeated fixes, revert frequency, and change hotspots;
- test health, missing regression coverage, flaky checks, and CI reliability;
- review latency, repeated review themes, oversized changes, and rework;
- operational load, incidents, dependency or release friction;
- documentation, onboarding, and recurring manual steps;
- decisions or shortcuts that accumulated follow-up cost.
Counts and code volume may provide context but are not success metrics by themselves. Inspect representative changes before explaining a trend. Label causal explanations as hypotheses unless direct evidence confirms them.
Compare
When comparison is requested or a compatible prior snapshot exists, compare equal-length periods with the same source definitions. Show absolute values and deltas, and call out changes in data availability. Do not claim improvement from small or noisy samples.
For team retrospectives, discuss ownership distribution, review coverage, and system bottlenecks without ranking individuals. Mention a person only to credit a concrete outcome or route an action when ownership is already known.
Report
Return:
- scope, refs, dates, and evidence limitations;
- outcomes shipped and meaningful wins;
- quality and delivery signals with supporting examples;
- trends versus the comparable period, when available;
- what helped, what created friction, and open hypotheses;
- at most five actions with expected benefit, measurable completion condition, and owner only when known;
- experiments to run before the next retrospective.
Write a snapshot or publish the report only when requested. Do not open issues, assign people, or change project state without separate authorization.
1---2name: engineering-retrospective3description: Produce an evidence-based engineering retrospective from delivery, test, review, incident, and workflow signals. Do not rank individuals or replace a postmortem.4---56# Engineering Retrospective78Review how the engineering system worked over a defined period. This is distinct from `postmortem`: it looks for recurring delivery and quality patterns even when no incident occurred. Keep the analysis blameless and resist turning activity volume into a productivity score.910## Establish the Window and Evidence1112- Resolve the repository, base branch, local timezone, and explicit period; default to the most recent seven complete days only when the user gave no window.13- Prefer a freshness-verified remote base when network access and authorization allow a fetch. Otherwise disclose the exact local ref and latest commit date.14- Collect available git history, merged pull requests, review cycles, test changes, CI outcomes, incidents, backlog movement, and release evidence. State which sources were unavailable.15- Normalize author aliases only when evidence supports the mapping. Do not infer performance, effort, or working hours from commit timestamps or line counts.1617## Analyze the System1819Look for evidence-backed patterns in:2021- delivered outcomes and work that remained unfinished;22- regressions, repeated fixes, revert frequency, and change hotspots;23- test health, missing regression coverage, flaky checks, and CI reliability;24- review latency, repeated review themes, oversized changes, and rework;25- operational load, incidents, dependency or release friction;26- documentation, onboarding, and recurring manual steps;27- decisions or shortcuts that accumulated follow-up cost.2829Counts and code volume may provide context but are not success metrics by themselves. Inspect representative changes before explaining a trend. Label causal explanations as hypotheses unless direct evidence confirms them.3031## Compare3233When comparison is requested or a compatible prior snapshot exists, compare equal-length periods with the same source definitions. Show absolute values and deltas, and call out changes in data availability. Do not claim improvement from small or noisy samples.3435For team retrospectives, discuss ownership distribution, review coverage, and system bottlenecks without ranking individuals. Mention a person only to credit a concrete outcome or route an action when ownership is already known.3637## Report3839Return:40411. scope, refs, dates, and evidence limitations;422. outcomes shipped and meaningful wins;433. quality and delivery signals with supporting examples;444. trends versus the comparable period, when available;455. what helped, what created friction, and open hypotheses;466. at most five actions with expected benefit, measurable completion condition, and owner only when known;477. experiments to run before the next retrospective.4849Write a snapshot or publish the report only when requested. Do not open issues, assign people, or change project state without separate authorization.
egeetas