| name | retro |
| description | Brutally honest engineering retrospective. Analyzes git history for what actually happened — not what people think happened. Gives blunt, specific, data-backed feedback per contributor. No vibes, only data. |
| user-invocable | true |
| argument-hint | [time range, e.g. 'last week', 'last 2 weeks', 'march'] |
Read ../_house-style/house-style.md before starting.
Anchor phrases
- Git is the source of truth. Not memory. Not standups. Not Slack.
- More commits does not mean more output. More LOC does not mean more value.
- "Great job everyone" is not feedback. It's the absence of feedback.
- Specific praise builds trust. Vague praise builds nothing.
Domain-specific examples
Contributor feedback — wrong way:
"Alice had a productive week with lots of commits. She's doing great work on the payment system. Keep it up!"
Contributor feedback — right way:
"Alice — 12 commits, +1.8k LOC, 8% test ratio, 3 PRs. All PRs under 200 LOC — disciplined. Shipped the Stripe webhook handler (app/services/webhooks/stripe.rb) with retry logic and idempotency keys — this is the kind of infrastructure that prevents 2am pages. Growth opportunity: test ratio at 8% on payment code is a liability. The webhook handler has no test for the duplicate-event path, which is the most common Stripe failure mode. Add integration tests for duplicate and out-of-order events before the next payment feature goes in."
Team observation — wrong way:
"Overall a productive week. We should try to write more tests and do code reviews faster."
Team observation — right way:
"14 PRs merged, 3 sat open for over 48 hours (PRs #89, #92, #94 — all waiting on Bob's review). Review bottleneck is measurable: those 3 PRs represent 4 days of blocked work. Either distribute review load (Alice reviewed 0 PRs this week) or set a 24-hour SLA. Test ratio dropped from 34% to 28% week-over-week. The decline is entirely in app/services/ — 6 new service files, 0 test files. This is debt accumulating in the most critical layer."
Data collection
From git history for the requested range:
Per-contributor: commits, LOC +/-, files touched, test LOC %, PR count/size, fix/revert ratio, active days, peak hours (from timestamps).
Team-level: total commits/LOC/PRs, hotspot files, biggest ship, revert ratio, test ratio.
Patterns: coding sessions (commit clusters), late-night commits (burnout signal), long branch gaps (blockers), stale PRs (review bottleneck), multi-person hotspot files (coordination risk).
Output format
Period summary
One paragraph: what shipped, in numbers. Not what was planned.
Biggest wins
Top 3. Specific: what, who, why it matters. From git.
Biggest problems
Top 3. Blunt. Evidence from git.
Per-contributor breakdown
For each:
- Stats: commits, LOC, test ratio, PRs, active days, peak hours
- What they shipped: specific, from git
- What went well: specific praise with evidence
- Growth opportunity: specific, actionable, engineering-practice-level
Hotspots
Most-modified files. Who touched them, how often, test coverage.
Risks
Trends: test coverage direction, PR size growth, bus factor changes, dep update freshness.
Three things to change
Specific, owned: what, who, by when, how you verify.
Devil's advocate
For your harshest per-person feedback: could external factors explain it? Blockers you don't see in git?
What I didn't check
Context I can't get from git: meetings, planning, blocked-on-others time.
