Change Throughput¶

ContributorsMyles Henaghan

When to use: Deliberately invoke in Agent mode against a git repository to produce a point-in-time read on Lead Time For Changes (LTFC), deployment or integration frequency, batch size, contributor mix, and an experimental change-failure proxy. Re-run periodically (for example monthly).

Instructions¶

Read references/change-throughput-prompt.md and follow the scope gate before any history commands.
Pull latest on the target clone (git fetch) before collecting. Do not assume the trunk is main — confirm with git ls-remote --symref origin HEAD.
Prefer the bundled scripts under scripts/ — stdlib only; no network and no writes to the target repo unless the user asks to save the report.
Run the unit tests before trusting engine output: python -m unittest discover -s scripts -p 'test_*.py' from this skill folder.
Confirm the deploy trigger and the merge style. Merge frequency is deployment frequency only when a merge to the trunk deploys. Squash-merge makes LTFC unmeasurable — report that, do not report 0h.
Report batch size with scripts/batch_size.py and the change-failure proxy with scripts/failures.py. Keep low-confidence failure candidates in a confirmation queue; do not fold them into the headline rate.
AUTHOR_ALIASES in metrics.py ships empty. Extend it for the target project in the working session. Do not commit customer emails or real names into this library.
Write one markdown report. Default save location is the portfolio scans folder the user confirms (often docs/management/compliance/scans/<repo_id>/). Do not write into the target repo unless asked.

What this diagnostic covers¶

View	What it answers
Throughput	LTFC (first commit → merge to trunk) and DF (merges per week / work-day), split into meaningful vs micro changes
Contributor mix	Who is genuinely active vs occasional; concentration / bus-factor
Benchmark check	Actual vs 1 good change per N active contributors per work-day (default N=2)
Batch size	Net commits, churn, and batch age per landing
Change-failure proxy	How often a landing is followed by a fix-like change, with a confidence tier

References¶

Troubleshooting¶

Symptom	Likely cause	Fix
Zero PRs in window	Host does not write `pull request #N` merge subjects	Enumerate merges another way or widen subject matching
Inflated contributor count	Same person under multiple git identities	Extend `AUTHOR_ALIASES` in `metrics.py` for the target project
DF mislabelled	Merges do not deploy	Relabel as integration frequency; note the real deploy gate
Distorted LTFC	History rewriting or squash merges	Check author vs committer dates; if landings are squashes, report LTFC as not measurable
Inflated PR count	History walked without `--first-parent`	Re-collect with first-parent only
Portfolio table missing a repo	Review markdown skipped a registry id, or a release-train repo needs two rows	Run `scripts/verify_portfolio_throughput_tables.py` against the registry and the review