Hi folks, I maintain repowise, a self hosted tool that indexes a repo on your own machine and scores how risky every file in it is. I wanted the kind of signal codescene gives you without uploading my codebase to somebody else's server, and I wanted the same commit to produce the same number on every run so I could put it in CI and trust it

So the scoring engine has no llm. It uses 49 determinstic checks over AST and your git history, 26 of them defect markers, uses python on top of tree-sitter and git data already in your repo. Takes approx 30 secs to run for a 3k file repo

Every file gets 3 scores - Defect risk, maintainability for duplication and cohesion, and performance, which traces N+1 queries and I/O inside loops through the call graph across file boundaries. That last one catches the cases where the loop sits in one file and the query sits in another, which a file-local linter cannot see

I recently quit my job to build this full time after saw some enterprise inbounds. I was a data scientist for 7.5 years before this.

I also benchmarked it on 2826 files, 21 repos, 9 languages, each scored at a commit before the bug window so nothing leaks backward, then checked against the next 6 months of fixes. ROC AUC 0.737, and 2.3x the defects found per unit of review budget compared to codescene on the same files and labels. It reruns that check on your repo after indexing and prints the result

Same index also gives you a local dashboard, a wiki generated from the code, dead code detection, and an MCP server so your coding agent reads the same data instead of grepping blind, all served from localhost

Runs as a Docker container, compose file is in the repo, or pip install repowise. Indexing and scoring dont need llm. The only piece that wants an llm is the wiki prose which is optional (and ollama can be used there)

Its AGPL, 6k+ stars, and we now have 65+ awesome contributors

https://github.com/repowise-dev/repowise

Issues and contributions welcome!

My wife and I always wanted to build something together, so we spent nights and weekends shipping side projects. One hit 25k users on its own but didn't feel like the thing worth quitting for, repowise did

That one came out of watching coding agents work. I'd been building with LLMs since 2023 and owned the AI architecture at my company, so I spent a lot of time watching agents grep the same file four times in a session and still have no idea which parts of the codebase were fragile or why the code was written that way. All of it is in the repo already, just not in a form an agent can use.

So we built Repowise. It indexes your repo once and serves it to your agent over MCP as five layers: dependency graph, git history, docs, architectural decisions, and a code health score from around 25 deterministic markers with no LLM involved. Pulling the context around a single commit costs about 393 tokens instead of roughly 14,000 spent reading files.

We didnt do any outbound, just shipped code and wrote about it. 4 months in it's at 5.2k stars, ~80k PyPI downloads, and enterprise inbounds I never asked for, which is why I quit

Benchmarked against four other tools plus a bare agent: 31% fewer output tokens over a full 48-question run, ~97% on a single context load, and the best gold-file coverage of the field on retrieval.

Repo: https://github.com/repowise-dev/repowise

Stars help, issues and contributions welcome

Let me give some background first.

My wife and I always wanted to build a company together. We started building and marketing some side projects on weekends and nights, nothing too serious just shipping things and seeing what worked, One of our side project was working great as well, organically reached 25k users but we weren’t satisfied enough to take it full time.

I've also worked with LLMs since 2023 and built a bunch of internal AI systems at my company over those years, including a multi-agent platform that ended up used across the company so I got promoted to senior staff along the way and ended up owning the AI architecture company wide.

Work was good but the itch to build our own thing never went away. So we started Repowise on the side. It's an open source codebase intelligence layer for AI coding agents. Your agent stops greping the same file four times and actually understands your repo: dependency graph, git history, docs, architectural decisions, and a code health score etc etc

We didnt do any outbounds just shipped it, wrote about it on our socials, and let people find it, been 3 months now.

It grew on its own, 4.3k+ stars, around 60k downloads on PyPI. Then enterprises started reaching out, all inbound. That was the signal I needed, so I left my job to do this full time.

Still early and still terrifying but so far the user response has been exciting, We had focused mainly on perfecting the product and little bit organic marketing, Time to give it our everything now

Link: https://github.com/repowise-dev/repowise

If you like it, a star would be helpful. Contributions and issues are most welcome!

Architecture diagrams have two failure modes. Three boxes that say nothing, or a hairball of two thousand nodes that says everything at once, which is also nothing. Both get screenshotted for a deck and never opened again.

Neiither answers the question you actually have in a new repo, which is not "what connects to what". It is "where am I, and does this matter".

So I built the other thing. A map you zoom into

The whole repo is one card. Zoom in and it opens into layers, then folders, then files, then functions. It is continuous, like a map app going from country to street. No level dropdown, no reload, no re-layout between steps, so you never lose your place.

The key thing: you never look at the whole repo at once. At any level you see a handful of cards, and you dig deeper only where it matters. It is something you navigate, not one dense picture you stare at. And it is not drawn by hand. It is generated from the code and git history and stays current as you commit, so it cannot hallucinate a module or drift from reality.

What makes it readable:

Cards are sized by how the system runs, not by line count. Entry points, what everything routes through, what churns. The code you should look at first is physically the biggest thing on screen.

Each card carries a health dot, rolled up so a folder reflects everything inside it. You find the bad neighbourhood from orbit and then dive.

Edges only appear when you hover a box, and only that box's edges, curved around the other cards rather than through them. That single decision is most of the difference between a map and a hairball.

The performance answer, for anyone who assumes this dies at scale: you never draw the whole repo. Anything off screen or smaller than a couple of pixels is skipped, so a frame draws a few dozen cards whether the tree has 2,000 nodes or 10,000. Cost stops scaling with repo size, which was the point.

It is part of an open source tool I maintain called Repowise, AGPL, runs fully local. Gif is it mapping its own repo.

Link: https://github.com/repowise-dev/repowise

Edit: no, it's not just C4. C4 is four static diagrams you draw and maintain by hand. This is generated from code and git history, one continuous zoom, with card size from centrality and churn, plus co-change and health that C4 has no concept of

Edit 2: Thanks for all the feedback, the Structurizr DSL point came up enough that I am adding it as an export format, emitted as a model file you include from your own workspace so your views and styles stay yours and never get overwritten on re-index

It maps dependencies, git history, docs, architectural decisions, and code health, then flags files most likely to cause future bugs deterministically without llm,

Therefore, Less guessing, Fewer wasted tokens and produce bug free code with AI

https://github.com/repowise-dev/repowise

A few months ago I kept hitting the same problem with my business running in prod with 25k mau. I was working on it on the side and using claude to mostly code it , and there was a point where I had to be in the loop a lot than I had time for. I work really efficiently with agents, I led agent architecture at my workplace globally as a Senior Staff Data Scientist.

So I started building the thing I needed initially just for my side business. A local index that provides enriched context to claude code across graph, git history, living wiki, architectural decisions through git commit and PR mining, then I added a code health layer that scores every file for defect risk from deterministic markers. Code health became an interesting research problem for me as a data scientist. So I then used the dependency graph and git history to show where the risk sits and hands the agent a concrete fix to run. Split this god class, move this method, break this cycle.

We figured maybe a handful of people wanted their agent to stop grepping and their health score to point at the fix instead of just waving at it. So me and my co founder took it as our primary project and built an OSS around it.

Then the benchmarks came back better than I expected. Across 21 open-source repos the health score hits ROC AUC 0.74 at predicting which files get bug-fixed over the next six months, up to 0.90 on some. ( AUC means if you give it one bad file and one good file, it correctly catches bad file with 74% accuracy and upto 90% in some repos) On the same 2,770 files scored against the same defect labels, it surfaces 2.3x the defects any other tool in market does under a fixed review budget. This turned out to be the best tool at prediction in the market and I initially ran it on 21 repos than a large repo- cockroach DB and it produced promising results. Trying to publish a paper on this too. On the agent side, loading a commit's context runs about 27x cheaper than raw file reads, and agents make roughly 70% fewer tool calls at the same answer quality But yes context savings is something everyone doing rn. So just ran the benchmarks for fun

This week it crossed more than 50K pip installs and I keep refreshing the dashboard expecting it to correct itself. I also shipped a hosted website for it, never marketed it but two teams and multiple individual devs bought the subscription and worked as the early design partners to shape the product for me.

Also the fun thing here is, the coding agents we built this for were also building it with us. Two founders and a rotating council of Claudes doing the exploration. Using agents to build better context and health signals for agents, then watching those signals make the next version easier to ship.

Not pretending it was smooth. I rewrote the indexer more than once, the parser choked on real repos across a couple of the 15 languages before it didn't, and getting the defect calibration leakage-free, scoring at a historical commit and counting bug-fixes only after, took longer than the entire first prototype.

Repo's here if you want to poke at it: https://github.com/repowise-dev/repowise

It has reached 3.4k stars all organically now, happy to answer anything.

I've been building an open-source thing called Repowise and finally got a VS Code extension out for it. Sharing here because I want to know what's actually useful and what isn't.

What it does: it indexes your repo locally. Nothing goes to a server, it all stays on your machine. From that index it puts a few things in the editor that I got tired of checking in separate tools:

• Gutter markers and a health score for whatever file you're in. The markers come from static analysis calibrated against actual bug-fix history in the repo, so it's not just "this file is long."
• Refactoring suggestions show up as a CodeLens above the relevant code (extract a class, break a dependency cycle, split a file, that kind of thing). There's a button to copy the suggestion as a prompt if you want to hand it to Copilot or an agent.
• "Analyze Change Risk" in the Source Control tab. Before you push it tells you what your uncommitted changes affect downstream, which changed files don't have tests, files that usually change alongside the ones you touched but that you left alone, and who might be a good reviewer.
• The bigger views (health map, dependency graph, generated living wiki, knowledge graph etc which are native repowise offering) open in an editor tab instead of kicking you out to a browser.

One thing I ended up liking: the same local index also runs as an MCP server. So if you're using Copilot agent mode, or Cursor, or Claude, the agent pulls from the same index you're looking at instead of re-grepping the repo every time.

Free, AGPL-3.0. pip install repowise for the CLI, then grab "Repowise" from the Marketplace.

Marketplace: https://marketplace.visualstudio.com/items?itemName=repowise-dev.repowise
Source: https://github.com/repowise-dev/repowise

Diagnostics are off by default on purpose. I didn't want to add another extension that spams squiggles everywhere, so the signal sits quietly in the gutter and status bar instead. Mostly I want to hear whether that default feels right, and which parts are genuinely useful versus just noise.

Most codebase MCP servers wrap grep and file reads. I wanted my coding agent to answer the questions grep can't: which files actually carry the bugs, why is this code shaped this way, what breaks if I touch it. So I built an MCP server around a codebase engine, and the headline tool is a deterministic code-health score. I ran the whole thing on OpenClaw as a public test.

The headline tool: code health

get_health returns a 1 to 10 score per file from 25 deterministic biomarkers (complexity, duplication, ownership and churn, test gaps). No LLM in the scoring, so the same commit always gives the same number, which matters when an agent is making decisions off it. It splits into three views: defect risk, maintainability, and a static performance-risk pass.

On OpenClaw (18k files): average 6.83, maintainability 8.94, with risk concentrated in a few hotspots. The performance pass alone flagged 1312 I/O-in-a-loop shapes and 324 serial awaits that could fan out with Promise.all. An agent can read this before editing and know which files are landmines.

Live report you can click through: https://www.repowise.dev/repo/openclaw/openclaw/overview

The rest of the MCP surface

The same server exposes, all read-only:

- get_context: a verified skeleton of a file or symbol (signatures + the central bodies) at a fraction of a full read, so the agent spends fewer tokens to orient

- get_why: architectural-decision archaeology, falls back to git history when no decision record exists

- get_risk: churn, owners, and blast radius before a change; PR mode returns a will-break / missing-tests directive

- search_codebase: hybrid symbol / path / semantic search

- get_dead_code, get_symbol, get_overview

There is a trust protocol baked in: responses that were checked against the live working tree are marked verified, so the agent is told not to re-read those bytes that alone cut a lot of redundant file reads in practice.

The scoring and findings are static analysis over tree-sitter ASTs and git data, not an LLM grading your code. The docs/wiki layer uses an LLM, but the numbers an agent acts on are reproducible. We run these same tools against our own codebase, which is how most of the rough edges got found.

It works across 15 languages, runs locally, and is open source: https://github.com/repowise-dev/repowise

Feedback and contributions welcome!

Most "AI reviews your PR" tools annoy me. They hallucinate nits, the output changes every run, and you can't tell if a flag means anything. So I wanted to know if you can get a useful review signal the boring way. Static metrics plus git history, without any LLM in the loop, so same input gives the same output every time.

The question I actually wanted answered: do deterministic code-health metrics predict which files get bug-fixed later?

How I set it up :

• Score every file at a historical commit (T0).
• Count bug-fixing commits to that file over the next 6 months.
• Correlate the T0 score with the bug-fixes that came after. No file sees its own future.

Metrics are the usual suspects plus churn signals. McCabe complexity, deep nesting, LCOM4 cohesion, god classes, clone detection, function-level churn, code age, ownership spread, change entropy. 25 of them, combined into a 1-10 per file. I ran it across 21 OSS repos, 9 languages.

What came out:

• Mean ROC AUC 0.74 at picking the files that go on to get bug-fixes. Up to 0.90 on some repos, weaker on others.
• It survives controlling for file size (partial Spearman -0.16). So it's not just "big files have more bugs," which was my first worry.
• Out-ranks churn alone by about +0.10 AUC, and prior-defect history by +0.12.
• Held on an external dataset I never touched (PROMISE/jEdit), AUC ~0.77.

I ran it head to head against CodeScene too, same 2,770 files, same commit, same labels, since it's the closest established tool. Discrimination was close (0.73 vs 0.71). The gap showed up on effort-aware ranking. Under a "you only have time to review 20% of the changed lines" budget, the deterministic score surfaced more of the real defects (recall 0.17 vs 0.07, Popt 0.61 vs 0.46). Similar at telling risky from safe, better at ordering what to look at first.

Where it falls down, because 0.74 is not magic:

• It tells you where bugs cluster, not what the bug is.
• Ranks files, doesn't read them so not a review replacement.
• Defect labels come from bug-fix commits, which is a noisy heuristic. Some "fixes" aren't, some bugs never got a clean fix commit. That ceiling is baked in.
• The 6-month window is a choice. Move it and the numbers move.
• The CodeScene edge is specifically ranking under a budget. On raw "is this file risky, yes or no," they're close.

Where I landed: the signal is real and it's reproducible, which is the part I care about for PR gating but it won't catch a logic bug in a 4-line diff.

It's good at "this PR touches a file that's been a problem for a year with one owner, slow down." Different job than line-by-line review, and I think it's the job the deterministic approach is actually good at.

I have also added agent provenance to the same which allows it to determine if an AI PR is worse than human

If anyone wants to take a look at the repo: https://github.com/repowise-dev/repowise

Also, if you have any feedback on the metrics itself or if I can try some new metric, would love to try that

My agent kept saying "you're absolutely right" and I had transcripts of everything sitting in ~/.claude/projects. So I made the meeting official.

skiplevel reads those transcripts locally and generates a 360 review between you and your agent. It generates self-contained HTML file, without any uploads.

For my 632 sessions and 160k transcript lines, it took around 2 seconds.

uvx skiplevel

Mine found:

- Claude said "you're absolutely right" 56 times in 31 days

- It read the same file 30 times in a single session. 151 times overall

- I interrupted it 339 times and typed 3,025 words in ALL CAPS

- It once ran 299 tool calls in a row unsupervised

- Verdict: Agent A-, me B. I apologized to a language model 7 times, which it noted

You get graded on clarity, patience, civility, trust. The agent on eficiency, reliability, safety, composure. All deterministic, zero LLM by default, the full rubric is in the repo.

There's also a useful layer under the jokes: redundant reads, retry storms, sensitive file touches with timestamps, cost per session. It flagged every time the agent went near a .env or .ssh path.

Works on Codex CLI and opencode transcripts too. Optional --roast flag sends your stats (numbers only, never prompts or code) to your own claude CLI for custom commentary.

Built with Fable, so Claude wrote the tool that reviews Claude. It gave itself an A-.

MIT: https://github.com/repowise-dev/skiplevel

Would love to see what grades you guys get

I run Claude Code on Opus most of the day. Got tired of watching it cat the same file four times and read 300 lines of passing-test dots to find 4 failures.

So I made an OSS tool to fix this and then measured what it saved over a week.

Two sources of waste, two fixes

Command output: git diff, git log, pytest, build and lint floods. A filter compresses the output before the agent reads it. Errors first, exit code preserved, every omission reversible. git log and git diff land 86 to 89% smaller. Test runs about 60%

Retrieval: Instead of the agent grepping and opening 8 candidate files to answer one question, MCP tools hand back a curated answer. Each call replaces the raw file reads it stood in for

~41% of the savings came from retrieval, not the command-output compression everyone talks about

One heavy week on my own repo:

6.2M tokens saved on command output, 4.3M tokens saved on retrieval, 10.5M total, about $158 the agent never had to read, one-time indexing cost: $0.37 (nano model)

The token tracking is one layer. repowise also indexes the repo into five: graph (AST + call structure), git history (hotspots, ownership, bus factor), docs/wiki, architectural decisions, and code health

Dashboard screenshot below. All local, nothing leaves the machine, open source (AGPL)

Repo: https://github.com/repowise-dev/repowise

I've been building repowise which is an MCP server that feeds your codebase structure to AI coding agents so they get deep understanding of your codebase beyond Grep.

Most agents only see the file as it is. Repowise gives them more: the dependency graph, git history (hotspots, ownership, co-changes, bus factor), an auto-generated wiki, a health score per file and architectural decisions from your code

The Code Health layer runs 25 deterministic checks per file without using LLM. Each file gets a 1 to 10 score based on complexity, duplication, test coverage, and a few other signals.

I benchmarked the defect prediction against CodeScene on 21 repos across 9 languages. It can predict bugs with a 74% accuracy (higher than CodeScene). Full writeup is in the repo if someone is interested

Open source, works with Claude Code, Cursor, or anything MCP compatible. Plus you get this full web ui completely local

GitHub: https://github.com/repowise-dev/repowise

Feedback and contributions welcome!