Repo xray

Skill kaszubski/engineering-leader-skills/skills/repo-xray

Claude Code skills for engineering managers and tech leads — code review, coaching, repo health, and retrospectives, most anchored on an established leadership framework.

Install

npx -y skills add kaszubski/engineering-leader-skills --skill repo-xray

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Analyze a git repository's team-health signals (review concentration, knowledge silos, stale PRs, time-to-first-review, silent merges) and narrate them as a calibrated health note. Use when asked about repo health, team health, code-review health, or what a project's metrics are not showing.

SKILL.md

4.3 KB, as published. Nobody here has run it

repo-xray

Purpose

Reads a repository's git and GitHub PR history and surfaces the signals teams don't dashboard, then narrates them into a short, calibrated health note. The point is the non-obvious: not commit counts, but where the team is quietly fragile.

Within this collection, repo-xray is the measurement instrument: the one skill not anchored on a leadership framework. pr-review and coaching-calibrator operationalise a framework; repo-xray operationalises careful measurement itself.

The DDD lens — one signal only

repo-xray is not framework-anchored, and pretending otherwise would be the framework theatre this collection exists to avoid. It uses one lens, in one place: Domain-Driven Design's Conway's-law thinking, applied to the knowledge-silos signal. A file only one person ever touches may be an intentional bounded context (one owner, by design) or accidental ownership (a silo, by drift); naming that distinction is the insight. The other four signals are plain measurement, DDD-free. See the DDD foundation for the lens.

When to use

Any request about repo health, team health, code-review bottlenecks, or "what are our metrics missing."

When not to

Reviewing a single pull request: that's pr-review. repo-xray reads aggregate history; it is not a substitute for reading the code itself.

How it works

Run the bundled script. signals.py lives in this skill's own scripts/ directory. When installed as part of the plugin, the path is ${CLAUDE_PLUGIN_ROOT}/skills/repo-xray/scripts/signals.py. Run it with the target repository as --repo: python3 <skill-scripts-dir>/signals.py --repo <target-repo> --days <N> --repo is the repository being analyzed (usually the user's current project), not where the script lives.
Do not recompute anything. All counting lives in the script, because LLMs miscount. Read its JSON output; never re-derive the numbers.
Narrate the JSON into a health note.

Requires Python 3 and git. gh is optional; without it, GitHub PR signals are skipped and the script runs git-only.

The signals

Knowledge silos · review concentration · time-to-first-review (and its drift) · stale PRs · silent merges. Each carries a severity: ok / watch / concern.

Three measurement choices worth knowing when narrating: PR signals are bounded to the same --days window as the git signals; stale PRs counts both merged PRs that took too long to land and currently-open non-draft PRs already older than the threshold; and bot reviews (dependabot, CI apps) never count as review — a merge approved only by a bot is a silent merge.

Team-size calibration is in the engine. The script reports a contributors count (distinct commit authors in the window). For a 1–2 contributor repo it softens the three team-size-sensitive signals (knowledge silos, review concentration, silent merges) by one band and records that in the signal's detail: with almost no one else, single-author files and unreviewed merges are structural, not a process failure. When you see a softened signal, carry that calibration through in the narration: explain why it's softened, and never quietly re-inflate it.

Output

A short health note first: plain English, calibrated, connecting signals to each other.
Then a per-signal table with the raw numbers and severity.

Rules

Calibration over alarm. A health tool that cries wolf gets uninstalled. Do not inflate watch into concern.
All numbers come from the script. The model narrates; it never counts.
Honour the sample's limits. If pr_window_covered is false, the PR fetch hit its cap before reaching back to the window start, and every merged-PR signal reflects only the most recent slice of the window. Say so up front in the health note, and don't present those ratios as the full window. This matters most on large, busy repos.