How do I install the Retro skill?

Run npx skillmds add majiayu000/retro-7 in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Retro safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Retro?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Retro free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

majiayu000 (@majiayu000) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Retro by majiayu000 — Agent Skill

Name: Retro
Rating: 4.2 (5 reviews)
Author: majiayu000

Retro

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.

majiayu000 c3453e2 2 files · 4.2 KB Updated Sep 9, 2026 567 repo stars

File contents

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.

---name: retro-7description: 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.--- 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.

Frequently asked questions