Weekly build note: making repository health easier to inspect

[eshaanag]

This week I tightened the public surface of CommitIQ and wanted to document the direction clearly.

CommitIQ is built around one idea: GitHub activity alone is not enough to understand repository health. A project can look active while accumulating churn, ownership risk, dependency pressure, and architectural hotspots. The goal is to turn commit history into useful engineering signals that maintainers can inspect before the next release or refactor.

Current focus:

• Ingest a bounded slice of Git history safely.
• Score complexity, churn, dependency risk, semantic drift, and ownership concentration.
• Surface hotspots and bus-factor risk in a dashboard instead of burying them in raw logs.
• Use optional Claude or Gemini narratives to explain what changed across a set of commits.
• Keep local development reproducible with backend tests, frontend tests, linting, build checks, and repository hygiene guards.

The next product question is how opinionated the health score should be. I am leaning toward showing the raw signals first, then using the score as a summary rather than a black box. For developer tools, explainability matters more than a single impressive number.

Feedback I would find useful:

• Which repository health signals would you trust most?
• Should the dashboard optimize for maintainers, contributors, or reviewers first?
• What is the smallest useful demo repo size for showing the product properly?

Repo: https://github.com/eshaanag/CommitIQ---
Demo: https://commit-iq-iota.vercel.app