Repowise: one local index for the call graph, git history and dead code

repowise init runs graph, git, health and dead code in one pass

Repowise is a Python package that indexes a repository once, on your own machine, and then answers questions about that repository over MCP. One command does the work, and the flags on it decide how much prose gets written along the way. `repowise init --yes --no-prose` runs the graph, git, health, dead code and docs layers and skips model-written prose, which is what keeps the setup free of API calls. The README states that the graph, risk, health, tests and dead code layers make zero LLM calls, so no key is needed for the parts most people install it for. What does need a key is the option to have a model write the wiki prose instead of rendering it from structure. The package requires Python 3.11 or newer, ships as version 0.60.1, and pyproject.toml still labels it Development Status :: 3 - Alpha.

Every graph edge carries a label for how it was resolved

The call graph gets the most attention, and the detail that separates it from a text search sits on each edge: how the edge was resolved, and how far to trust it. Parsing runs through tree-sitter grammars rather than a compiler, and the Python package pins tree-sitter grammars for Python, TypeScript, JavaScript, Go, Rust and Java among others, while the README counts 28 languages overall. Layered on top sit every caller of what you changed, the files that usually change with it but are missing from your diff, and the tests that reach it.

Two kinds of documentation live in the same index

Ask for a wiki and you get one per module and file, rendered from the code's own structure with no key, or written by a model when you choose that path. Decisions are mined from ADRs, comments, commits, PRs and agent sessions, and owners come back alongside callers, risk and tests in one MCP answer.

Health scores inherit whatever test coverage you actually have

Test intelligence sits in the change risk layer: for what you changed, the README lists every caller, the files that usually change with it but are missing from your diff, and the tests that reach it. Code health is a separate layer, a 1 to 10 score for every file that the README says is validated against real bug history, feeding a ranked fix-first queue, refactoring plans and dead code. Coverage is something you add: after a first index, the dashboard's Setup page is where you connect agents, turn on sync and add coverage or a model, and the examples folder carries a health-coverage example. Find out whether your pipeline already writes a coverage file before you go looking for that setting.

The evidence table in the README cannot be rerun on your own code

The README leads with three numbers: half the tool calls (3.8 instead of 7.2, with 3.0 files opened instead of 7.2 and 31.6% less output in a measured run on django/django), up to 99% less noise from test runs, installs and git output with every error line kept, and 88% of the right files found in one call against 61% for the next best tool. On a small local model it puts the output cut at 47.9%. Those are the project's own measurements, and the method behind each one is in docs/BENCHMARKS.md, so read that before relying on a specific figure for your own codebase.

AGPL-3.0 and an Alpha tag decide more than taste does

The package is AGPL-3.0-or-later, so licensing is a decision rather than a footnote. If you wrap Repowise inside a service you hand to customers, the copyleft terms are the first thing to read closely. That is not legal advice and the LICENSE file is the authority. On the release side, v0.60.1 shipped on 2026-11-02, v0.60.0 on 2026-11-01 and v0.59.0 on 2026-10-25, and the last push to the default branch was on 2026-11-02. That cadence cuts both ways. Fixes and interface changes travel in the same stream, and pyproject.toml marks the project as alpha, so budget for reading release notes on upgrade instead of assuming a minor bump is safe.

A FastAPI schema change can fail the TypeScript type check

The repository is two projects sharing one tree. The Python side is a uv workspace whose Makefile carries generate-types, which regenerates the TypeScript HTTP contract from the FastAPI schema, and generate-types-check, which fails when that generated contract is stale. On the JavaScript side, the root package.json declares six workspaces: packages/types, packages/ui, packages/api-client, packages/web, packages/vscode and packages/claude-mod, and it requires Node 20 or newer. That file also pins a long overrides list, from next at about 15.5.28 through vite, esbuild, sharp, uuid, ws, serialize-javascript, postcss, js-yaml, dompurify, @babel/core and form-data. The practical effect is that a response model you edit in Python can break a build under packages/web until you regenerate the types, and every Node install pulls in a dependency floor you did not pick.

Install and first use with uv, pipx or pip

Install the package, move into the repository you want indexed, run init once, then serve. The three install routes differ only in how the tool lands on your PATH: uv keeps it isolated as a uv tool, pipx does the equivalent through pip, and pip drops it into whichever environment is active. The second command is where the index appears, and `--no-prose` is the flag that keeps model calls out of it. `serve` then opens the local dashboard and the MCP server that Claude Code, Codex or Cursor talk to. The README also offers a one line route, where the agent reads a setup document, does the wiring itself and asks before anything costs money:

uv tool install repowise          # or: pipx install repowise / pip install repowise
cd /path/to/your/repo
repowise init --yes --no-prose    # graph, git, health, dead code, docs. No key, no spend.
repowise serve                    # local dashboard + MCP server

After that, ask the agent to call `get_overview` on the repository, or to say what breaks if you change a file such as `src/auth.py`. init wires Claude Code on its own. Other MCP-capable agents need the MCP entry declared. If you would rather poke at the Python side while the index builds, the workspace has a fast test target that needs no API keys, and the Makefile targets reduce to these two lines:

uv sync --all-packages
uv run pytest tests/unit/ tests/providers/ -v -q

Run the second one after install; it covers unit and provider tests and skips the fixtures that want keys or a live index.

Editorial conclusion

Adopt Repowise if your agent keeps re-reading files to work out what calls what. Leave it alone if you need type level certainty that tree-sitter parsing cannot give you, or if AGPL-3.0 is not acceptable to your organisation. Before the first run, check whether your CI already emits a coverage file, because coverage is something you add in Setup, and read what the generate-types-check target does before you touch a FastAPI response model.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes