Find the code nothing uses, and know what is safe to delete.

It walks the dependency graph the index already holds. A file with no importer that is not an entry point is an unreachable file. A public, top-level symbol that no import, call, inheritance or type reference reaches is an unused export. A top-level package no other package imports is a zombie package. Each finding then gets a confidence from 0 to 1: git history sets the starting value, and signs of runtime loading lower it. The analysis runs as part of repowise init and repowise update.

A finding is marked safe to delete when its confidence is 0.7 or higher and its path carries no runtime-load risk factor, such as config, environment, bootstrap, database, script or served-asset paths. In practice that is an unused export with strong evidence. Unreachable files, zombie packages and unused internals stay review candidates whatever their confidence, because a build script or loader can read a file by path. In a workspace, a finding with a cross-repository note is never marked safe.

No. Code a framework calls by convention is exempt before scoring: entry points such as __main__.py, main.go and files with a shebang, build and CI files and anything they name by path, test files, generated code, vendored trees, framework routes such as Next.js page files, and symbols registered by a decorator or annotation, including pytest fixtures, Flask and FastAPI routes, Celery tasks and Spring stereotypes. Names that follow dispatch conventions such as *Handler, *Plugin, register_* and on_* are treated as used.

Yes. Inside one repository, zombie packages are the top-level packages nothing else imports. Across a repowise workspace, each finding is checked against the other repositories before it is tiered: when another repository's HTTP route or generated client points at the file, confidence drops to 30 percent of its value and the finding names the consumer, and co-change with files in other repositories adds a note. Run it per repository with repowise dead-code --repo, or ask an agent for get_dead_code(repo="all").

It runs on the dependency graph, so it covers the languages repowise resolves imports for, from Python, TypeScript and JavaScript to Go, Ruby, PHP and Rust. Findings on Java, C#, C, C++, Kotlin and Swift are served as a preview with the measurement behind each one. Dynamic-import markers such as importlib.import_module, require.context, Class.forName and dlopen lower the confidence of nearby files in 14 languages. Rust private items are left to the compiler's own dead_code lint.

Through the get_dead_code MCP tool, which is on by default. get_dead_code(tier="high", safe_only=True) returns the deletion-ready findings, each with its confidence, reason, evidence and the file's primary owner. You can filter by kind, directory or owner, group results by directory or owner, and open one finding by id. The agent sees the same tiers as the CLI and the dashboard, so a finding lands in the same place on every surface.

It changed recently, it has little history, or a cap fired. A file with a commit in the last 90 days starts at 0.4, because recent work is often unfinished; a file under 30 days old starts at 0.55 and one with no git history at 0.5. Otherwise a cap holds it at 0.4: a runtime loader in the same directory, a path that looks like config or bootstrap code, the symbol's name written elsewhere in the repository, or a name that appears in a file repowise could not index. Each cap adds a line to the finding's evidence, so the report tells you which one applied.