repository-health-review

Assessing repository health

Produce an evidence-backed picture of how a repository is doing across a few independent dimensions.

This workflow makes no changes. Every tool it uses is read-only. If a specific issue, alert or pull request needs action, that is separate work — name it and hand it over rather than starting it here.

Sequence

Gather each dimension independently, so one unavailable source does not sink the report.

1. Activity. list_commits with since set to ninety days ago gives commit volume and who is contributing. list_releases gives cadence — the gaps between published_at values say more than the count.
2. Branch hygiene. list_branches, then check the age of each branch's head commit. Many long-untouched branches usually mean the project does not prune, which is a mild signal on its own and a stronger one alongside slow pull request flow.
3. Flow. list_pull_requests with state: open, sort: created and direction: asc puts the oldest first; the age of the oldest and the shape of the distribution are the numbers worth reporting. list_issues with state: OPEN, orderBy: CREATED_AT and direction: ASC does the same for issues.
4. CI reliability. actions_list with method: list_workflow_runs, filtered to the default branch, over a recent window. The ratio of conclusion: success to failures on the default branch is the signal; failures on feature branches are expected and are not.
5. Maintainer coverage. list_repository_collaborators shows how many people can maintain the repository. One active committer is a risk worth naming plainly.
6. Outstanding risk. list_code_scanning_alerts and list_dependabot_alerts with state: open, counted by severity only. Do not open individual alerts here.
7. Report per dimension, each with the numbers behind it, and state which dimensions could not be assessed.

Decision points

• Absent history is not poor health. A repository with few commits, no releases and no alerts may be new. Say insufficient history rather than scoring it.
• Low activity is not decay. A stable, finished library should look quiet. Weigh activity against open issues and unanswered pull requests, not on its own.
• What counts as stale depends on the project's own cadence. Derive the threshold from its release and merge intervals rather than importing a fixed number, and state the threshold you used.
• When to stop. This produces an assessment. If it surfaces something urgent — a critical alert, a default branch that has been failing for weeks — name it clearly and hand it over.