[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-74236":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":18,"stars30d":19,"stars90d":16,"forks30d":16,"starsTrendScore":20,"compositeScore":21,"rankGlobal":10,"rankLanguage":10,"license":22,"archived":23,"fork":23,"defaultBranch":24,"hasWiki":23,"hasPages":25,"topics":26,"createdAt":10,"pushedAt":10,"updatedAt":37,"readmeContent":38,"aiSummary":39,"trendingCount":16,"starSnapshotCount":16,"syncStatus":40,"lastSyncTime":41,"discoverSource":42},74236,"repowise","repowise-dev\u002Frepowise","repowise-dev","Codebase intelligence for AI-assisted engineering teams: code health scores, auto-generated docs, git analytics, dead code detection, and architectural decisions via MCP.","https:\u002F\u002Frepowise.dev",null,"Python",2254,294,8,16,0,51,145,803,153,29.41,"Other",false,"main",true,[27,28,29,30,31,32,33,34,35,36],"ai","claude","code-intelligence","dead-code","developer-tools","documentation","git-analytics","mcp","open-source","python","2026-06-12 02:03:24","\u003Cdiv align=\"center\">\n\n\u003Cimg src=\".github\u002Fassets\u002Flogo.png\" width=\"280\" alt=\"repowise\" \u002F>\u003Cbr \u002F>\n**The codebase intelligence layer for your AI coding agent.**\n\nFour intelligence layers. Seven MCP tools. Multi-repo workspaces. Auto-sync hooks. One `pip install`.\n\n[![PyPI version](https:\u002F\u002Fimg.shields.io\u002Fpypi\u002Fv\u002Frepowise?color=F59520&labelColor=0A0A0A)](https:\u002F\u002Fpypi.org\u002Fproject\u002Frepowise\u002F)\n[![License: AGPL v3](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Flicense-AGPL--v3-F59520?labelColor=0A0A0A)](https:\u002F\u002Fwww.gnu.org\u002Flicenses\u002Fagpl-3.0)\n[![Python](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fpython-3.11%2B-F59520?labelColor=0A0A0A)](https:\u002F\u002Fpypi.org\u002Fproject\u002Frepowise\u002F)\n[![MCP](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FMCP-compatible-F59520?labelColor=0A0A0A)](https:\u002F\u002Fmodelcontextprotocol.io)\n[![Stars](https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Fstars\u002Frepowise-dev\u002Frepowise?color=F59520&labelColor=0A0A0A)](https:\u002F\u002Fgithub.com\u002Frepowise-dev\u002Frepowise)\n\n[**Explore real codebases →**](https:\u002F\u002Fwww.repowise.dev\u002Fexplore) · [**Hosted for teams →**](https:\u002F\u002Fwww.repowise.dev\u002F#contact) · [**Docs**](https:\u002F\u002Fdocs.repowise.dev) · [**Discord**](https:\u002F\u002Fdiscord.gg\u002FcQVpuDB6rh) · [**Contact**](mailto:hello@repowise.dev)\n\n---\n\n\u003Cimg src=\".github\u002Fassets\u002Fdemo.gif\" alt=\"repowise demo — repowise init → Claude Code querying via MCP tools\" width=\"100%\" \u002F>\n\n---\n\n\u003C\u002Fdiv>\n\nYour AI coding agent reads files. It doesn't know which ones change together, which ones are dead, or why they were built the way they were. It has the source code and no memory of how the codebase got there.\n\nrepowise fixes that. It indexes your codebase into four intelligence layers — dependency graph, git history, auto-generated documentation, and architectural decisions — and exposes them to Claude Code (and any MCP-compatible AI agent) through seven precisely designed tools. Multi-repo? Initialize a workspace and get cross-repo co-change detection, API contract extraction, and federated MCP queries across all your services. **27× fewer tokens per query. 36% cheaper. Same answer quality.**\n\nThe result: your agent answers *\"why does auth work this way?\"* instead of *\"here is what auth.ts contains.\"*\n\n---\n\n## 🏆 Benchmarked against frontier LLMs\n\n> **[repowise-bench →](https:\u002F\u002Fgithub.com\u002Frepowise-dev\u002Frepowise-bench)** — an open SWE-QA benchmark that grades how well standard LLMs answer real software-engineering questions over real repositories.\n>\n> On 48 paired tasks from `pallets\u002Fflask` (`claude-sonnet-4-6`, end-to-end), repowise-augmented Claude Code matches baseline answer quality while being dramatically leaner:\n>\n> | Metric (per task, mean) | Baseline | **+ repowise** | Δ |\n> |---|---|---|---|\n> | 💰 Cost | $0.1396 | **$0.0890** | **−36 %** |\n> | ⚡ Wall time | 41.7 s | **33.9 s** | **−19 %** |\n> | 🛠️ Tool calls | 7.4 | **3.8** | **−49 %** |\n> | 📄 Files read | 1.9 | **0.2** | **−89 %** |\n>\n> **32 \u002F 48 (67 %)** tasks are cheaper with repowise — at parity quality (judge Δ ≈ −0.01).\n\n### Token efficiency — because context windows aren't free\n\nThere's a small genre of \"token efficiency\" benchmarks going around. It would be impolite not to contribute one. Ours runs on the 30 most recent non-merge commits of `pallets\u002Fflask` and asks one question: *to understand a commit, how many tokens does each strategy ask the model to read?*\n\n| Strategy | Tokens \u002F commit |\n|---|---|\n| Naive (full contents of changed files) | 64,039 |\n| `git diff` only | 14,888 |\n| **`repowise get_context`** | **2,391** |\n\n**209× less than naive (mean), 26.8× pooled, 1,214× best case. 41.7× less than git diff (mean), 6.2× pooled.** Same file list, same tokenizer (`cl100k_base`), no per-strategy fudge. We report mean, pooled, and median together because picking just one would be the kind of thing other people in this genre seem to do.\n\n> Full methodology, per-task tables, and the actual SWE-QA evaluation (which has third-party ground truth and an independently-scored LLM judge — unlike this sanity-check): **[repowise-bench →](https:\u002F\u002Fgithub.com\u002Frepowise-dev\u002Frepowise-bench)**\n\n---\n\n## What repowise builds\n\nrepowise runs once, builds everything, then keeps it in sync on every commit.\n\n### ◈ Graph Intelligence\ntree-sitter parses every file across 14 languages into a two-tier dependency graph — file nodes and symbol nodes (functions, classes, methods). A 3-tier call resolver with confidence scoring handles import aliases, barrel re-exports, and namespace imports. Heritage extraction covers extends, implements, trait impls, derive macros, mixins, and extension conformance. Leiden community detection finds logical modules even when your directory structure doesn't reflect them. PageRank, betweenness centrality, SCC analysis, and execution flow tracing from entry points identify your most central, most coupled, and most traversed code.\n\n### ◈ Git Intelligence\nYour git history turned into signals: hotspot files (high churn × high complexity), ownership percentages per author, co-change pairs (files that change together without an import link — hidden coupling), and significant commit messages that explain *why* code evolved. Rolled up into **contributor profiles** (per-author module rollups, top files, co-authors, silo modules, dead-code burden), **module health scorecards** (composite score over churn × ownership × docs × dead code × bus factor), and **reviewer suggestions** for any PR file list, weighted by direct authorship, co-change history, and recency.\n\n### ◈ Documentation Intelligence\nAn LLM-generated wiki for every module and file, rebuilt incrementally on every commit. Coverage tracking. Freshness scoring per page. Semantic search via RAG. Confidence scores show how current each page is relative to the underlying code.\n\n### ◈ Decision Intelligence\nThe layer nobody else has. Architectural decisions captured from git history, inline markers, and explicit CLI — linked to the graph nodes they govern, tracked for staleness as code evolves.\n\n```python\n# WHY: JWT chosen over sessions — API must be stateless for k8s horizontal scaling\n# DECISION: All external API calls wrapped in CircuitBreaker after payment provider outages\n# TRADEOFF: Accepted eventual consistency in preferences for write throughput\n```\n\nThese become structured decision records, queryable by Claude Code via `get_why()`.\n\n---\n\n## Quickstart\n\n```bash\npip install repowise\n```\n\nOr install the CLI into an isolated, uv-managed environment:\n\n```bash\nuv tool install repowise\n```\n\n### Single repo\n\n```bash\ncd your-project\nrepowise init        # builds all four intelligence layers (~25 min first time)\nrepowise serve       # starts MCP server + local dashboard\n```\n\n### Multi-repo workspace\n\n```bash\ncd my-workspace\u002F     # parent dir containing backend\u002F, frontend\u002F, shared-libs\u002F\nrepowise init .      # scans for git repos, indexes each, runs cross-repo analysis\nrepowise serve       # workspace dashboard + per-repo pages\n```\n\nThat's it. `repowise init` automatically registers the MCP server, installs PreToolUse\u002FPostToolUse hooks in `~\u002F.claude\u002Fsettings.json`, generates `.mcp.json` at the project root, and offers to install a post-commit git hook that keeps everything in sync after every commit. See [Auto-Sync](docs\u002FAUTO_SYNC.md) for all sync methods (hooks, file watcher, GitHub\u002FGitLab webhooks, polling).\n\nTo manually add the MCP server to another editor:\n\n```json\n{\n  \"mcpServers\": {\n    \"repowise\": {\n      \"command\": \"repowise\",\n      \"args\": [\"mcp\", \"\u002Fpath\u002Fto\u002Fyour\u002Fproject\"]\n    }\n  }\n}\n```\n\n> **Note on init time:** Initial indexing analyzes your entire codebase — AST parsing, git-history mining, LLM doc generation, embedding indexing, and decision archaeology. This is a one-time cost (~25 minutes for a 3,000-file project). Every subsequent update after a commit takes under 30 seconds and only regenerates the few pages affected by your changes.\n\n> **Full docs:** [Quickstart](docs\u002FQUICKSTART.md) · [User Guide](docs\u002FUSER_GUIDE.md) · [CLI Reference](docs\u002FCLI_REFERENCE.md) · [MCP Tools](docs\u002FMCP_TOOLS.md) · [Workspaces](docs\u002FWORKSPACES.md) · [Computed Glossary](docs\u002FCOMPUTED_GLOSSARY.md) · [Auto-Sync](docs\u002FAUTO_SYNC.md)\n\n---\n\n## Workspaces — multi-repo intelligence\n\nMost codebases aren't one repo. repowise workspaces let you index and query multiple repositories together — with cross-repo intelligence that single-repo tools can't provide.\n\n```bash\ncd my-workspace\u002F          # backend\u002F, frontend\u002F, shared-libs\u002F under one parent\nrepowise init .           # scan, select repos, index each, run cross-repo analysis\n```\n\n**What you get on top of per-repo intelligence:**\n\n| Feature | What it does |\n|---|---|\n| **Cross-repo co-changes** | Finds files across repos that change in the same time window — e.g., `backend\u002Fapi\u002Froutes.py` and `frontend\u002Fsrc\u002Fapi\u002Fclient.ts` always move together |\n| **API contract extraction** | Scans for HTTP route handlers (Express, FastAPI, Spring, Go), gRPC service defs, and message topic publishers\u002Fsubscribers — then matches providers with consumers across repos |\n| **Package dependency mapping** | Reads `package.json`, `pyproject.toml`, `go.mod`, `pom.xml` to detect when one repo depends on another as a package |\n| **Federated MCP queries** | One MCP server serves all repos. Pass `repo=\"backend\"` or `repo=\"all\"` to any tool |\n| **Workspace dashboard** | Aggregate stats, repo cards, contract links, co-change pairs — all in the web UI |\n| **Workspace CLAUDE.md** | Auto-generated context file covering all repos, their relationships, and cross-repo signals |\n\n**Workspace CLI:**\n\n```bash\nrepowise workspace list                  # show all repos and their status\nrepowise workspace add ..\u002Fnew-service    # add a repo (auto-indexes + docs by default)\nrepowise workspace remove api-gateway    # remove a repo (doesn't delete files)\nrepowise workspace scan                  # re-scan for new repos\nrepowise update --workspace              # update all stale repos + first-time index any new ones\nrepowise update --repo backend           # scope to one repo (auto-detected from cwd too)\nrepowise watch --workspace               # auto-update all repos on file change\nrepowise doctor --workspace --repair     # validate every repo; sync state drift; drop dead entries\nrepowise hook install --workspace        # install post-commit hooks for all repos\n```\n\nMost commands also accept `--no-workspace` to force single-repo mode and `--repo \u003Calias>` to scope to one repo. See [CLI Reference](docs\u002FCLI_REFERENCE.md#workspace-auto-detect-cross-cutting).\n\nFull guide: [docs\u002FWORKSPACES.md](docs\u002FWORKSPACES.md)\n\n---\n\n## Seven MCP tools\n\nMost tools are designed around data entities — one module, one file, one symbol — which forces AI agents into long chains of sequential calls. repowise tools are designed around **tasks**. Pass multiple targets in one call. Get complete context back. Full reference: [docs\u002FMCP_TOOLS.md](docs\u002FMCP_TOOLS.md)\n\n| Tool | What it answers | When Claude Code calls it |\n|---|---|---|\n| `get_overview()` | Architecture summary, module map, entry points, git health, community summary | First call on any unfamiliar codebase |\n| `get_answer(question)` | One-call RAG: retrieves over the wiki, gates on confidence, and synthesizes a cited 2–5 sentence answer. High-confidence answers cite directly; ambiguous queries return ranked excerpts. | First call on any code question — collapses search → read → reason into one round-trip |\n| `get_context(targets, include?)` | The workhorse. Docs, symbols, ownership, freshness, community membership for any targets. `include` options: `\"source\"` (symbol body), `\"callers\"`\u002F`\"callees\"` (call graph), `\"metrics\"` (PageRank, centrality), `\"community\"` (cluster membership). Batch multiple targets. In workspace mode, pass `repo` to target a specific repo. | Before reading or modifying code. Pass all relevant targets in one call. |\n| `search_codebase(query)` | Semantic search over the full wiki. Natural language. In workspace mode, searches across all repos. | When `get_answer` returned low confidence and you need to discover candidate pages by topic |\n| `get_risk(targets?, changed_files?)` | Hotspot scores, dependents, co-change partners, blast radius, recommended reviewers, test gaps, security signals, 0–10 risk score | Before modifying files — understand what could break |\n| `get_why(query?)` | Three modes: NL search over decisions · path-based decisions for a file · no-arg health dashboard | Before architectural changes — understand existing intent |\n| `get_dead_code(min_confidence?, include_internals?)` | Unreachable code sorted by confidence tier with cleanup impact estimates | Cleanup tasks |\n\n### Tool call comparison — a real task\n\n*\"Add rate limiting to all API endpoints.\"*\n\n| Approach | Tool calls | Time to first change | What it misses |\n|---|---|---|---|\n| Claude Code alone (no MCP) | grep + read ~30 files | ~8 min | Ownership, prior decisions, hidden coupling |\n| **repowise (7 tools)** | **5 calls** | **~2 min** | **Nothing** |\n\nThe 5 calls for that task:\n\n```python\nget_overview()                                         # orient: understand the architecture\nget_context([\"middleware\", \"api\u002Froutes\", \"payments\"])  # understand 3 modules at once\nget_risk([\"middleware\u002Fauth.ts\"])                       # assess: 47 dependents, co-changes\nget_why(\"rate limiting\")                               # check: any prior decision?\nsearch_codebase(\"rate limit OR throttle OR retry\")     # find: any prior implementation?\n```\n\n---\n\n## How Claude Code uses it\n\n```\nUser: Implement rate limiting on all API endpoints\n\nClaude Code:\n→ get_overview()\n  \"Express API. Entry points in api\u002Froutes\u002F. Middleware in middleware\u002F.\"\n\n→ get_context([\"middleware\", \"api\u002Froutes\", \"payments\"])\n  middleware\u002F: existing chain is cors → auth → routes. Owner: @alex.\n  api\u002Froutes\u002F: 23 route files. No existing rate limiting.\n  payments\u002F: Owner @sarah (71%). Decision: all side effects must be idempotent.\n\n→ get_why(\"rate limiting\")\n  \"No prior decision found. No prior implementation detected.\"\n\n→ get_risk([\"middleware\u002Fauth.ts\"])\n  \"47 files import this. Co-changes with all 4 service listeners.\n   Risk summary: any interface change here touches 47 dependents.\"\n\n→ search_codebase(\"rate limit throttle retry\")\n  \"Found: payments\u002Fretry.ts already has RetryQueue class.\n   Found: payments\u002Fmiddleware.ts has idempotency key middleware.\"\n\nImplementing rate-limiting middleware, inserting after cors, before auth.\nWill also update tests\u002Fmiddleware.test.ts — detected as historical co-change partner.\nFlagging payments\u002F for @sarah review — hotspot, high ownership concentration.\n```\n\nThis is what happens when an AI agent has real codebase intelligence.\n\n---\n\n## Local dashboard\n\n`repowise serve` starts a full web UI alongside the MCP server. No separate setup — browse your codebase intelligence directly in the browser.\n\n\u003Cimg src=\".github\u002Fassets\u002Fwebui.gif\" alt=\"repowise web UI\" width=\"100%\" \u002F>\n\n| View | What it shows |\n|---|---|\n| **Chat** | Ask anything about your codebase in natural language |\n| **Docs** | AI-generated wiki with syntax highlighting, Mermaid diagrams, and a graph intelligence sidebar showing PageRank\u002Fbetweenness percentiles, community membership, and degree |\n| **Graph** | Interactive dependency graph — handles 2,000+ nodes. Community color mode with real labels, community detail panel on click, path finder |\n| **C4 Architecture** | C4-model view of the codebase (Context → Containers → Components) with drill-down, URL-synced state, and a per-node detail panel that surfaces module health, top contributors, and the generated wiki page inline |\n| **Search** | Full-text and semantic search with global command palette (Ctrl+K) |\n| **Symbols** | Searchable index of every function, class, and method, server-ranked by importance (PageRank × visibility × complexity × kind × entry-point). Filter facets for public-only, language, kind, in-hotspot-files, and in-entry-point-files. Click any symbol for graph metrics, callers\u002Fcallees, class heritage, and a git panel with governing decisions |\n| **Coverage** | Doc freshness per file with one-click regeneration |\n| **Risk** | One page, six tabs: Hotspots (with inline drill-down to the top importance-ranked symbols in each file), Heatmap (ownership treemap with bus-factor borders and silo overlay), Module Health, Dead Code, Impact (blast radius), and the always-visible risk strip linking to each |\n| **Contributors** | Paginated contributor directory and per-author profile pages — modules they own, top files, co-authors, commit category mix, silo modules, bus-factor risk files, and dead-code burden. Click any owner anywhere in the dashboard to drill in |\n| **Module Health** | Per-module rollup with a composite health score (churn \u002F ownership \u002F docs \u002F dead code \u002F bus factor), sortable list, and a per-module detail page showing owners, top hotspots, and governing decisions |\n| **Hotspots** | Ranked by trend-weighted score (180-day decay) and churn. Paginated load-more; each row expands inline to the most important symbols in that file |\n| **Dead Code** | Unused code with confidence scores, owner leaderboard, and bulk actions |\n| **Decisions** | Architectural decisions with staleness monitoring. Decision detail has a writable module-linkage editor so a decision's governance scope can be edited and shows up on the linked module's health page |\n| **Costs** | LLM spend by day, model, or operation, with running session totals |\n| **Blast Radius** | Paste a PR file list, see transitive impact, test gaps, and a ranked reviewer-suggestions panel weighted by direct authorship, co-change history, and recency |\n| **Security** | Local regex-based scan for dangerous patterns — `eval`\u002F`exec`\u002F`pickle.loads`\u002F`shell=True`\u002F`os.system`, hardcoded secrets, f-string and concat SQL, `verify=False`, weak hashes — surfaced with severity and grouped by directory. Runs in seconds, no LLM, no network |\n| **Knowledge Map** | Top owners, bus-factor silos, and onboarding targets on the dashboard |\n| **Graph Intelligence** | Architecture communities with expandable detail, execution flows with call traces, community coupling analysis — all on the overview dashboard |\n| **Workspace Dashboard** | Aggregate stats across repos, repo cards, cross-repo intelligence summary (workspace mode) |\n| **Workspace Contracts** | Detected API contracts (HTTP, gRPC, topics) with provider\u002Fconsumer matching across repos |\n| **Workspace Co-Changes** | Cross-repo file pairs ranked by co-change strength |\n| **System Health** | SQL\u002Fvector\u002Fgraph drift status from the atomic store coordinator |\n\n---\n\n## Proactive context enrichment — hooks\n\nMost MCP tools are passive — the agent has to know to call them. repowise hooks are **active**. They inject graph context into every search automatically, so agents are smarter even when they don't explicitly ask for help.\n\n### PreToolUse — every search gets graph context\n\nWhen your AI agent runs `Grep` or `Glob`, repowise intercepts the call and enriches it with the top 3 related files — found via multi-signal search (symbol name match, file path match, and full-text search on wiki content), ranked by relevance then PageRank:\n\n- **Symbols** — top functions, classes, and methods in each file\n- **Imported by** — who depends on this file\n- **Uses** — what this file depends on\n\nNo LLM calls. No network. Pure local SQLite queries.\n\n```\n[repowise] 3 related file(s) found:\n\n  src\u002Fcore\u002Fingestion\u002Fgraph.py\n    Symbols: class:GraphBuilder, method:__init__, method:build\n    Imported by: src\u002Fcore\u002Fingestion\u002F__init__.py\n    Uses: src\u002Fcore\u002Fanalysis\u002Fcommunities.py, src\u002Fcore\u002Fanalysis\u002Fexecution_flows.py\n\n  src\u002Fcore\u002Fingestion\u002F__init__.py\n    Imported by: src\u002Fcli\u002Fcommands\u002Fupdate_cmd.py, src\u002Fcore\u002Fpipeline\u002Forchestrator.py\n    Uses: src\u002Fcore\u002Fingestion\u002Fgraph.py\n```\n\n### PostToolUse — auto-detect stale wiki\n\nAfter a successful `git commit`, repowise checks whether the wiki is out of date and notifies the agent:\n\n```\n[repowise] Wiki is stale — last indexed at commit a1b2c3d4, HEAD is now f9a0499b.\nRun `repowise update` to refresh documentation and graph context.\n```\n\nHooks are installed automatically during `repowise init`. No manual configuration needed. Full details: [docs\u002FAUTO_SYNC.md](docs\u002FAUTO_SYNC.md)\n\n---\n\n## Auto-sync — five ways to keep your wiki current\n\nrepowise keeps your intelligence layers in sync with your code. Pick the method that fits your workflow:\n\n| Method | Command | Best for |\n|--------|---------|----------|\n| **Post-commit hook** | `repowise hook install` | Set-and-forget local development |\n| **File watcher** | `repowise watch` | Active development without committing |\n| **GitHub webhook** | Configure in repo settings | Teams, CI\u002FCD |\n| **GitLab webhook** | Configure in project settings | Teams, CI\u002FCD |\n| **Polling fallback** | Automatic with `repowise serve` | Safety net for missed webhooks |\n\n```bash\n# Install post-commit hook for one repo\nrepowise hook install\n\n# Install for all repos in a workspace\nrepowise hook install --workspace\n\n# Check hook status\nrepowise hook status\n\n# Or use the file watcher\nrepowise watch                    # single repo\nrepowise watch --workspace        # all workspace repos\n```\n\nA typical single-commit update touches 3–10 pages and completes in under 30 seconds. Full guide: [docs\u002FAUTO_SYNC.md](docs\u002FAUTO_SYNC.md)\n\n---\n\n## Auto-generated CLAUDE.md\n\nAfter every `repowise init` and `repowise update`, repowise regenerates your `CLAUDE.md` from actual codebase intelligence — not a template. No LLM calls. Under 5 seconds.\n\n```bash\nrepowise generate-claude-md\n```\n\nThe generated section includes: architecture summary, module map, hotspot warnings, ownership map, hidden coupling pairs, active architectural decisions, and dead code candidates. A user-owned section at the top is never touched.\n\n```markdown\n\u003C!-- REPOWISE:START — managed automatically, do not edit -->\n## Architecture\nMonorepo with 4 packages. Entry points: api\u002Fserver.ts, cli\u002Findex.ts.\n\n## Hotspots — handle with care\n- payments\u002Fprocessor.ts — 47 commits\u002Fmonth, high complexity, primary owner: @sarah\n- shared\u002Fevents\u002FEventBus.ts — 23 dependents, co-changes with all service listeners\n\n## Active architectural decisions\n- JWT over sessions (auth\u002Fservice.ts) — stateless required for k8s horizontal scaling\n- CircuitBreaker on all external calls — after payment provider outages in Q3 2024\n\n## Hidden coupling (no import link, but change together)\n- auth.ts ↔ middleware\u002Fsession.ts — co-changed 31 times\n\u003C!-- REPOWISE:END -->\n```\n\n---\n\n## Git intelligence\n\nrepowise mines your git history (per-file, configurable depth) to produce signals no static analysis can find.\n\n**Hotspots** — files in the top 25% of both churn and complexity. These are where bugs live. Flagged in the dashboard, in CLAUDE.md, and surfaced by `get_risk()` before Claude Code touches them.\n\n**Ownership** — `git blame` aggregated into ownership percentages per author. Know who to ping. Know where knowledge silos exist.\n\n**Co-change pairs** — files that change together in the same commit without an import link. Hidden coupling that AST parsing cannot detect. `get_context()` surfaces co-change partners alongside direct dependencies.\n\n**Bus factor** — files owned >80% by a single author. Shown in the ownership view. Surfaced in CLAUDE.md as knowledge risk.\n\n**Significant commits** — the last 10 meaningful commit messages per file (filtered: no merges, no dependency bumps, no lint) are included in generation prompts. The LLM explains *why* code is structured the way it is.\n\n**Contributor profiles** — every author with commits gets a profile page: modules they own, top files, co-authors, commit category mix (feat \u002F fix \u002F refactor \u002F docs \u002F test \u002F chore \u002F perf), silo modules they're solely on, bus-factor risk files, and dead-code burden. Surfaced via `\u002Frepos\u002F\u003Cid>\u002Fowners` in the dashboard and linked from every owner reference.\n\n**Module health** — composite 0–100 score per top-level module derived from silo penalty, hotspot density, dead-code percentage, average churn, doc coverage, and median bus factor. Surfaced on the Risk page and the per-module detail page, with cross-links to owners, hotspots, and governing decisions.\n\n**Reviewer suggestions** — paste a PR file list into Blast Radius and get a ranked list of likely reviewers, scored by direct authorship (×1.0), co-change partners (×0.5), and recency (×0.4), capped at the 5 strongest co-change signals per file.\n\n---\n\n## Dead code detection\n\nPure graph traversal and SQL. No LLM calls. Completes in under 10 seconds for any repo size.\n\n```\nrepowise dead-code\n\n  23 findings · 4 safe to delete\n\n  ✓ utils\u002Flegacy_parser.ts          file      1.00   safe to delete\n  ✓ auth\u002Fsession.ts                 file      0.92   safe to delete\n  ✓ helpers\u002FformatDate              export    0.71   safe to delete\n  ✓ types\u002FOldUser                   export    0.68   safe to delete\n  ✗ analytics\u002Fv1\u002Ftracker.ts         file      0.41   recent activity — review first\n```\n\nConservative by design. `safe_to_delete` requires confidence ≥ 0.70 and excludes dynamically-loaded patterns (`*Plugin`, `*Handler`, `*Adapter`, `*Middleware`). Dynamic import detection (`importlib.import_module()`, `__import__()`) and framework awareness (Flask\u002FFastAPI\u002FDjango\u002FRails\u002FLaravel\u002FTYPO3 routes and convention files) further reduce false positives. repowise surfaces candidates. Engineers decide.\n\n---\n\n## Architectural decisions\n\n```bash\nrepowise decision add              # guided interactive capture (~90 seconds)\nrepowise decision confirm          # review auto-proposed decisions from git history\nrepowise decision health           # stale, conflicting, ungoverned hotspots\n```\n\n```\nrepowise decision health\n\n  2 stale decisions\n    → \"JWT over sessions\" — auth\u002Fservice.ts rewritten 3 months ago, decision may be outdated\n    → \"EventBus in-process only\" — 8 of 14 governed files changed since recorded\n\n  1 conflict\n    → payments\u002F: two decisions with overlapping scope and contradictory rationale\n\n  1 ungoverned hotspot\n    → payments\u002Fprocessor.ts — 47 commits\u002Fmonth, no architectural decisions recorded\n```\n\nDecisions are linked to graph nodes, tracked for staleness as code evolves, and surfaced by `get_why()` whenever Claude Code touches governed files.\n\nThe \"why\" usually walks out the door — when a teammate leaves, or when you reopen your own repo six months later. Decision intelligence keeps it in the codebase.\n\n---\n\n## How it compares\n\n| | repowise | Google Code Wiki | DeepWiki | Swimm | CodeScene |\n|---|---|---|---|---|---|\n| Self-hostable, open source | ✅ AGPL-3.0 | ❌ cloud only | ❌ cloud only | ❌ Enterprise only | ✅ Docker |\n| Auto-generated documentation | ✅ | ✅ Gemini | ✅ | ✅ PR2Doc | ❌ |\n| Private repo — no cloud | ✅ | ❌ in development | ❌ OSS forks only | ✅ Enterprise tier | ✅ |\n| Dead code detection | ✅ | ❌ | ❌ | ❌ | ❌ |\n| Git intelligence (hotspots, ownership, co-changes) | ✅ | ❌ | ❌ | ❌ | ✅ |\n| Bus factor analysis | ✅ | ❌ | ❌ | ❌ | ✅ |\n| Architectural decision records | ✅ | ❌ | ❌ | ❌ | ❌ |\n| Multi-repo workspace intelligence | ✅ co-changes, contracts, federated MCP | ❌ | ❌ | ❌ | ❌ |\n| MCP server for AI agents | ✅ 7 tools | ❌ | ✅ 3 tools | ✅ | ✅ |\n| Proactive agent hooks | ✅ PreToolUse + PostToolUse | ❌ | ❌ | ❌ | ❌ |\n| Auto-generated CLAUDE.md | ✅ | ❌ | ❌ | ❌ | ❌ |\n| Doc freshness scoring | ✅ | ❌ | ❌ | ⚠️ staleness only | ❌ |\n| Incremental updates on commit | ✅ \u003C30s | ✅ | ❌ | ✅ | ✅ |\n| Local dashboard \u002F frontend | ✅ | ❌ | ❌ | ❌ IDE only | ✅ |\n| Free for internal use | ✅ | ✅ public repos | ✅ public repos | ❌ | ❌ |\n\n**The honest summary:**\n\n- **vs Google Code Wiki** — Google's offering (launched Nov 2025) is cloud-only with no private repo support yet. Gemini-powered docs are strong, but there's no git behavioral intelligence, no dead code detection, no MCP server, and no architectural decisions.\n- **vs DeepWiki** — Cloud-only, closed source (community self-hostable forks exist). Strong docs and Q&A, with a basic 3-tool MCP server. No git analytics, no dead code, no decisions.\n- **vs Swimm** — Swimm's strength is keeping manually-written docs linked to code snippets with staleness detection. No graph, no git behavioral analytics, no dead code, no MCP by default. Enterprise pricing for private hosting.\n- **vs CodeScene** — CodeScene has excellent git intelligence (hotspots, co-changes, ownership, bus factor). No documentation generation, no RAG, no architectural decisions. Closed source, per-author pricing.\n\nrepowise is the intersection: CodeScene-level git intelligence + auto-generated documentation + agent-native MCP + architectural decisions + multi-repo workspace intelligence, self-hostable and open source.\n\n---\n\n## Hosted version — for teams\n\n[**repowise.dev**](https:\u002F\u002Fwww.repowise.dev) is the same engine, fully managed. Now at feature parity with self-hosted: every CLI command, every MCP tool, the full dashboard. Connect your IDE to the hosted MCP endpoint and skip the install entirely.\n\nWe use it on our own codebase — see the live snapshot of repowise indexing itself: [**dogfood example →**](https:\u002F\u002Fwww.repowise.dev\u002Fs\u002F5a6b93fa9a69). More public repos indexed on the [**explore page →**](https:\u002F\u002Fwww.repowise.dev\u002Fexplore).\n\n**What you get on top of self-hosting:**\n- **Zero ops** — managed deploys, managed webhooks, auto re-index on every commit, no infrastructure\n- **Hosted MCP endpoint** — point Claude Code (or any MCP client) at one URL, no local server to run\n- **CVE-aware security layer** — on top of the local pattern scan, the hosted version adds CVE-aware vulnerability detection, dependency risk surfacing, and cross-repo security anti-pattern analysis\n- **Cross-repo intelligence at scale** — federated hotspots, dead code, and ownership across all your repos in one dashboard\n- **Integrations** *(rolling out)* — Slack alerts, Jira\u002FLinear decision linking, Confluence\u002FNotion doc sync, PagerDuty escalation\n\n[Get in touch →](https:\u002F\u002Fwww.repowise.dev\u002F#contact) · [hello@repowise.dev](mailto:hello@repowise.dev)\n\n---\n\n## CLI reference\n\n```bash\n# Core\nrepowise init [PATH]              # index codebase (one-time, offers hook setup)\nrepowise init --index-only        # graph + git + dead code, no LLM, no cost\nrepowise init -x vendor\u002F -x proto\u002F  # exclude patterns (gitignore syntax)\nrepowise init --include-submodules   # include git submodule directories\nrepowise update [PATH]            # incremental update (\u003C30 seconds)\nrepowise update --workspace       # update all stale repos in workspace\nrepowise update --repo backend    # update a specific workspace repo\nrepowise serve [PATH]             # MCP server + local dashboard\nrepowise watch [PATH]             # auto-update on file save\nrepowise watch --workspace        # auto-update all workspace repos\n\n# Auto-sync hooks\nrepowise hook install             # install post-commit hook (current repo)\nrepowise hook install --workspace # install for all workspace repos\nrepowise hook status              # check if hooks are installed\nrepowise hook uninstall           # remove hooks\n\n# Query\nrepowise query \"\u003Cquestion>\"       # ask anything from the terminal\nrepowise search \"\u003Cquery>\"         # semantic search over the wiki\nrepowise status                   # coverage, freshness, dead code summary\n\n# Dead code\nrepowise dead-code                          # full report\nrepowise dead-code --safe-only              # only safe-to-delete findings\nrepowise dead-code --min-confidence 0.8     # raise the confidence threshold\nrepowise dead-code --include-internals      # include private\u002Funderscore symbols\nrepowise dead-code --include-zombie-packages  # include unused declared packages\nrepowise dead-code resolve \u003Cid>             # mark resolved \u002F false positive\n\n# Cost tracking\nrepowise costs                    # total LLM spend to date\nrepowise costs --by operation     # grouped by operation type\nrepowise costs --by model         # grouped by model\nrepowise costs --by day           # grouped by day\n\n# Decisions\nrepowise decision add             # record a decision (interactive)\nrepowise decision list            # all decisions, filterable\nrepowise decision confirm \u003Cid>    # confirm a proposed decision\nrepowise decision health          # stale, conflicts, ungoverned hotspots\n\n# Editor files\nrepowise generate-claude-md       # regenerate CLAUDE.md\n\n# Proactive hooks (auto-installed by init — not called manually)\nrepowise augment                  # enriches agent tool calls with graph context\n\n# Utilities\nrepowise export [PATH]            # export wiki as markdown files\nrepowise export --full --format json  # full export with decisions, dead code, hotspots\nrepowise doctor                   # check setup, API keys, store drift\nrepowise doctor --repair          # check and fix detected store mismatches\nrepowise reindex                  # rebuild vector store (no LLM calls)\n```\n\n---\n\n## Supported languages\n\n| Tier | Languages | What works |\n|------|-----------|------------|\n| **Full** | Python · TypeScript · JavaScript · Java · Go · Rust · C++ · C# | AST parsing, import resolution, named bindings, call resolution, heritage extraction, docstrings; multi-project workspace resolvers (`.csproj`\u002F`.sln` for C#, `Cargo.toml [workspace]` for Rust, `go.mod` multi-module, `package.json` workspaces, etc.); framework-aware edges (Django, FastAPI, Flask, ASP.NET, Spring Boot, Express\u002FNestJS, Gin\u002FEcho\u002FChi, Axum\u002FActix); per-language dynamic-hint extractors for runtime-resolved DI \u002F reflection \u002F plugins |\n| **Good** | C · Kotlin · Ruby · Swift · Scala · PHP | AST parsing, import resolution, named bindings, call resolution, heritage (mixins, derive, extensions, traits), docstrings, dedicated workspace-aware resolvers (Gradle subprojects, Rails \u002F Zeitwerk, SPM, SBT\u002FMill, composer PSR-4); Rails \u002F Laravel \u002F TYPO3 framework edges for Ruby and PHP; per-language dynamic-hint extractors |\n| **Config \u002F data** | OpenAPI · Protobuf · GraphQL · Dockerfile · Makefile · YAML · JSON · TOML · SQL · Terraform | Included in the file tree; special handlers extract endpoints\u002Ftargets where applicable |\n\n14 languages with full AST support, 8 of them at the Full tier. Adding a new language requires one `.scm` tree-sitter query file and one config entry. No changes to the parser core. See [Language Support](docs\u002FLANGUAGE_SUPPORT.md) for details.\n\n---\n\n## Privacy\n\n**Self-hosted:** Your code never leaves your infrastructure. No telemetry. No analytics. Zero.\n\n**BYOK:** Bring your own Anthropic or OpenAI API key. We never see your LLM calls. Zero data retention via Anthropic's API policy — your code is never used to train any model.\n\n**What is stored:** NetworkX graph (file and symbol relationships, communities, call edges with confidence), LanceDB embeddings (non-reversible vectors), generated wiki pages, git metadata. Raw source code is processed transiently and never persisted.\n\n**Fully offline:** Ollama for LLM + local embedding models = zero external API calls.\n\n---\n\n## Configuration\n\n`repowise init` generates `.repowise\u002Fconfig.yaml`. Key options:\n\n```yaml\nprovider: anthropic               # anthropic | openai | openrouter | gemini | deepseek | ollama | litellm | mock\nmodel: claude-sonnet-4-5\nembedding_model: voyage-3\nreasoning: auto                   # auto | off | minimal\n\ngit:\n  co_change_commit_limit: 500\n  blame_enabled: true\n\ndead_code:\n  enabled: true\n  safe_to_delete_threshold: 0.7\n\nmaintenance:\n  cascade_budget: 30              # max pages fully regenerated per commit\n  background_regen_schedule: \"0 2 * * *\"\n```\n\n`reasoning` applies to documentation generation. `auto` preserves provider\ndefaults; explicit `off` \u002F `minimal` modes are translated only by providers and\nmodels that support them, otherwise repowise fails before making an API call.\n\nFull configuration reference: [docs\u002FCONFIG.md](docs\u002FCONFIG.md)\n\n---\n\n## Contributing\n\n```bash\ngit clone https:\u002F\u002Fgithub.com\u002Frepowise-dev\u002Frepowise\ncd repowise\nuv sync --all-packages\nuv run repowise --version\nuv run pytest tests\u002Funit\u002F\n```\n\nRun commands through uv without activating the environment:\n\n```bash\nuv run repowise --help\n```\n\nOr activate the local environment created by `uv sync`:\n\n```bash\nsource .venv\u002Fbin\u002Factivate\nrepowise --help\n```\n\nFull guide including how to add languages and LLM providers: [CONTRIBUTING.md](CONTRIBUTING.md)\n\n---\n\n## License\n\nAGPL-3.0. Free for individuals, teams, and companies using repowise internally.\n\nFor commercial licensing — embedding repowise in a product, white-labeling, or SaaS use without AGPL obligations — contact [hello@repowise.dev](mailto:hello@repowise.dev).\n\n---\n\n\u003Cdiv align=\"center\">\n\nBuilt for engineers who got tired of watching their AI agent `cat` the same file for the fourth time.\n\n[repowise.dev](https:\u002F\u002Frepowise.dev) · [Explore →](https:\u002F\u002Fwww.repowise.dev\u002Fexplore) · [Discord](https:\u002F\u002Fdiscord.gg\u002FcQVpuDB6rh) · [X](https:\u002F\u002Fx.com\u002Frepowisedev) · [hello@repowise.dev](mailto:hello@repowise.dev)\n\n\u003C\u002Fdiv>\n","repowise 是一个为AI辅助工程团队设计的代码库智能层，提供自动生成文档、Git分析、死代码检测以及通过MCP进行架构决策等功能。项目采用Python语言编写，具备四大智能层面：依赖图谱、Git历史记录、自动化文档生成和架构决策，并通过七个精心设计的工具将这些信息暴露给Claude Code或其他兼容MCP的AI代理。特别适用于需要跨多个仓库工作的场景，能够显著减少查询时所需的令牌数量（27倍更少），同时保持答案质量不变，且成本降低36%。这使得开发人员可以更加高效地理解代码结构与变更历史，从而提升软件开发效率。",2,"2026-06-11 03:49:37","high_star"]