Repo Xray

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

1. 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 /signals.py --repo --days --repo is the repository being analyzed (usually the user's current project), not where the script lives.

1. Do not recompute anything. All counting lives in the script, because LLMs miscount. Read its JSON output; never re-derive the numbers.
2. 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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: kaszubski
• Source: kaszubski/engineering-leader-skills
• License: MIT

Install and usage instructions live in the source repository linked above.