---
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.