What this prompt does
This prompt turns Claude Code into a forensic auditor of your git history. Instead of asking for an opinion on the current code, it points Claude at the log — commits, diffs, PRs, authorship — over a window you choose, and asks ten specific, computable questions: hotspots, bug-fix frequency by directory, churn (add/delete ratio), commit-size and author distribution, PR quality, file coupling, debt signals in messages, recommendations, change risk, and bus factor.
It works because every one of those ten outputs is derivable from data Claude Code can actually read with git log, git log --numstat, and gh pr list. The numbered structure forces the model to treat history as a dataset rather than guess. Hotspots come from change counts, coupling from files co-occurring in commits, bus factor from author concentration per directory. Nothing here asks Claude to invent — it asks it to aggregate and interpret what your repo already recorded.
When to use it
- Onboarding to an unfamiliar codebase and you want the risky, high-churn areas before you touch anything.
- Pre-refactor planning — find the files that change together so you scope the blast radius correctly.
- A quarterly engineering-health review for stakeholders who want evidence, not vibes.
- Spotting a module that's quietly accumulating bug fixes (a stability red flag).
- Identifying bus-factor-1 directories before a key engineer goes on leave or leaves.
- Reviewing whether your team's PRs are getting larger and slower over time.
Example output
HOTSPOTS (last 90 days)
app/Services/Billing.php 47 commits ⚠ 19 were bug fixes
resources/views/checkout.blade 31 commits
COUPLING (changed together >80% of the time)
Billing.php ⇄ InvoiceObserver.php (24/27 commits)
BUS FACTOR
app/Services/Billing/ ← 91% by one author RISK: HIGH
RISK FOR UPCOMING CHANGES
Touching Billing.php = high churn + bug-prone + single owner.
Recommend: pair review + characterization tests first.
Pro tips
- Set
[time_period]to match a release cadence (one quarter), not "all time" — old churn drowns recent signal and skews hotspots toward founding commits. - Bug-fix detection is only as good as your commit hygiene. If you prefix fixes (
fix:,bug:) or reference issue IDs, tell Claude the convention so #2 and #7 are accurate. - For
[pr_count], 20–30 is the sweet spot — enough to see PR-size and review-latency trends without flooding the context window. - Ask for
[report_format]as Markdown for a readme, or JSON when you want to feed the hotspot/coupling data into a dashboard or follow-up script. - Pair it with a second pass: take the top hotspot it finds and run a focused code review on that one file. History tells you where the risk is; the file read tells you what it is.
