History that writes the documentation.
repowise reads your git history for the behavioral signals static analysis cannot see: where the risk concentrates, who owns what, and which files secretly change together. Deterministic, from your history alone, with no LLM in the loop.
Your code tells you what it does. Only your history tells you how it actually behaves, where bugs keep landing, who is the only person who understands a module, and which files quietly change together.
A snapshot of the source misses all of that. repowise reads the git history every team already has and turns it into the behavioral signals that decide where real risk and knowledge concentration live.
The behavioral layer your linter can't see.
Hotspots, hidden coupling, and ownership, all deterministic and read straight from git.
Where the defects actually concentrate
A hotspot is a file in the top 25 percent of both churn and complexity. Files that change constantly and are hard to reason about are where bugs cluster, so repowise ranks them first instead of drowning you in every complex file you never touch.
- Top 25 percent of both churn and complexity, not either alone
- Churn from git history, complexity from the parsed code
- Ranked so the riskiest files surface first
- Deterministic, recomputed on every commit
The dependencies your graph never sees
Two files that always change together in the same commits are coupled, even when no import edge connects them. Your dependency graph misses this entirely. git history does not. repowise surfaces these co-change partners so you know what to touch together.
- Co-change partners mined from commit history
- Coupling without an import link, invisible to static analysis
- Surfaced per file and in PR risk reviews
- Cross-repo co-changes across service boundaries
Who owns what, and where the risk hides
From git blame alone, repowise computes the primary owner and top contributors for every file. It then flags bus-factor risk: files owned more than 80 percent by a single author, the key-person risk you want to know about before someone leaves.
- Primary owner and top contributors per file from git blame
- Bus factor: files owned over 80 percent by one author
- Contributor profiles across the codebase
- Reads commits only, no surveillance and no IDE plugins
From file signals to a worklist
Individual file signals roll up into a composite health view per module, and the same history powers reviewer suggestions. Change a set of files and repowise derives the right reviewers from the blast-radius file list.
- Composite module-health rollup across files
- Reviewer suggestions from the blast-radius file list
- Blast radius: every dependent a change could affect
- Surfaced in get_risk and get_context over MCP
Deterministic, from history to signal.
Read history
repowise reads your git log and blame and parses the repo into a dependency graph. No code leaves your infrastructure.
Derive signals
Churn, complexity, co-change pairs, and per-file ownership are computed deterministically, with no LLM in the path.
Rank risk
Hotspots (top 25 percent of churn and complexity) and bus-factor files (over 80 percent single-author) are ranked and rolled up per module.
Act
Reviewer suggestions, blast radius, and co-change partners surface in the dashboard, in PR reviews, and over MCP.
History, everywhere it helps.
In your AI agent
get_risk and get_context hand agents hotspots, co-change partners, and ownership over MCP.
On every PR
The Repowise PR Bot comments on hotspots, hidden coupling, and declining health, deterministically, with zero LLM calls.
In the dashboard
Dedicated Hotspots, Contributors, Module Health, and Blast Radius views over your real history.
For ownership
Primary owner and top contributors per file, with bus-factor flags for key-person risk.
For reviewers
Suggested reviewers derived from the blast-radius file list, not guesswork.
For leaders
Risk and knowledge concentration tied to code health and AI provenance on one surface.
Static analysis sees a snapshot. repowise sees how the code actually evolves, which is where risk and knowledge concentration really live.
Questions, answered
What is a hotspot?
A hotspot is a file in the top 25 percent of both churn and complexity. Churn comes from your git history, complexity from the parsed code. Files that are both change a lot and are hard to reason about are where defects concentrate, so repowise ranks them first. The signal is fully deterministic, computed straight from history with no LLM.
What is hidden coupling, or co-change?
Hidden coupling is a pair of files that repeatedly change together in the same commits without an import edge between them. Your dependency graph never sees this relationship because there is no code link, but git history reveals it. repowise surfaces these co-change partners so you know which files you probably need to touch together, even when nothing in the code says so.
How is bus factor calculated?
Bus factor flags files owned more than 80 percent by a single author. Ownership is derived from git blame: repowise attributes lines to contributors per file, identifies the primary owner, and marks any file where one person holds over 80 percent of the code as key-person risk. It is the part of your codebase most exposed if that person leaves.
Where does ownership come from?
Ownership comes from git blame, nothing else. repowise reads your existing history to compute the primary owner and the top contributors for every file. There are no IDE plugins, no instrumentation, and no developer surveillance. It reads commits, it does not watch people.
Does it use an LLM?
No. Every git-intelligence signal is deterministic: hotspots, co-change coupling, ownership, bus factor, module health rollups, and reviewer suggestions are all computed directly from your git history and dependency graph. The same history always produces the same result, with no cloud calls and no drift.
How is this different from static analysis?
Static analysis sees a snapshot of the code as it is right now. repowise sees how the code actually evolves over time, which is where risk and knowledge concentration really live. A linter cannot tell you that two unrelated files always change together, who is the only person who understands a module, or which files defects keep landing in. History can.
What are reviewer suggestions based on?
When you change a set of files, repowise computes the blast radius, the dependents that change could affect, and suggests reviewers from the ownership of that file list. Instead of guessing who should look at a pull request, you get the people who actually own the code in its path, derived from git blame and the dependency graph.
Can I see this on a real repository?
Yes. Every signal is open source and runs on public repos in the Explore section, so you can inspect hotspots, ownership, co-change pairs, and module health on real codebases before pointing repowise at your own. The same numbers are reachable by AI agents through the get_risk and get_context MCP tools.