# GitNexus for Claude Code: what it does and how to install it > GitNexus is a Claude Code plugin that indexes a codebase into a knowledge graph, then adds 13 skills, 7 review agents, and one MCP server on top of it. Use it to explore or debug unfamiliar code, check what a change might break, plan and execute an edit safely, or run a multi-agent review of a pull request. Canonical: https://www.flowy.sh/plugins/abhigyanpatwari-gitnexus/guide Published: 2026-10-29 Updated: 2026-10-29 Author: Flowy ## What is GitNexus? GitNexus describes itself as a zero-server code intelligence engine. Instead of grepping a repository fresh for every question, it indexes the whole codebase once into a knowledge graph of dependencies, call chains, clusters, and execution flow, then lets Claude query that graph directly rather than re-reading files. Flowy indexes the plugin from its public repository, `abhigyanpatwari/GitNexus`, which sits in the development category and carries 45,750 GitHub stars as of the last crawl. Flowy does not host or bundle the code itself, so both the source and the real install command live at [the install card on the listing page](https://www.flowy.sh/listings/abhigyanpatwari-gitnexus#install). The plugin ships 21 components: 7 agents, 13 skills, and 1 MCP server. ## How does it turn a repository into something Claude can query? Two components handle that groundwork. `gitnexus-cli` covers the commands that build and maintain the index: an analyze or index pass over a repository, a status check on how stale that index has gotten, cleaning it out, generating a wiki from it, and listing what has already been indexed. `gitnexus` is the plugin's one MCP server, the piece that actually answers questions against the graph once it exists; the repository documents it as exposing search, impact analysis, tracing, and rename operations to a connected agent, so a session can query an already built index instead of rereading the repository each time. When the question is about GitNexus itself rather than the target codebase, `gitnexus-guide` is the skill to reach for: which tools exist, how to query the graph, and what its schema looks like. ## Which skills help you read and debug code you didn't write? `gitnexus-exploring` is for architecture questions on unfamiliar code: how something works, what calls a given function, or tracing an execution flow such as an auth path. `gitnexus-debugging` runs the opposite direction, tracing why something is failing or where an error actually comes from. Both work against the graph GitNexus already built instead of re-reading the repository from scratch on every question. ## Which skills help you plan and make a change without breaking something? Four skills chain into one workflow. `gitnexus-impact-analysis` answers "what will break" before an edit happens, by checking what depends on the code in question. `gitnexus-refactoring` covers renaming, extracting, splitting, moving, or restructuring code safely. `gitnexus-plan` turns a task into an implementation-ready plan built from the graph, statement-level program-dependence analysis, and targeted source checks, compact enough that another agent can start executing it without re-investigating first. `gitnexus-work` then executes a plan like that, or a small bounded task on its own, running an impact check before every symbol edit, running the tests named in the plan's own scenarios, and gating each commit on a change-detection check. `gitnexus-lfg` chains the two together end to end: pick a plan depth up front, hit a blocking gate to either execute with `gitnexus-work` or stop, and finish with a `gitnexus-review` of the result. ## What do the taint analysis and PDG skills add? Two skills cover a deeper, optional analysis layer built on control flow and program dependence graphs. `gitnexus-taint-analysis` is for working on or extending that subsystem, or for reasoning about a source-to-sink data flow finding, such as why a check missed a flow or where to add a new sink. `gitnexus-pdg-query` is for querying the program dependence graph's control and data dependence edges directly, answering questions like what guards a given statement or where a variable's value actually flows. Both are specialist tools, worth reaching for once a question is already a data-flow question rather than a general "how does this work." ## How does the pull request review pipeline work? `gitnexus-review` runs a single review pass from a GitHub PR URL or number, a branch or commit range, or local uncommitted changes, and produces a merge-risk read, a regression check, and a missing-test check. `gitnexus-pr-swarm-review` runs a production-readiness version of the same idea through a coordinated swarm of the plugin's seven agents, each covering one angle. `gitnexus-pr-facts-historian` gathers the PR's own GitHub history, changed files, commits, and linked issues. `gitnexus-branch-hygiene-reviewer` checks mergeability, conflicts, and stale branches. `gitnexus-security-boundary-reviewer` checks auth, secrets, injection, and unsafe parsing. `gitnexus-risk-architect` builds a risk model around runtime behavior and user impact. `gitnexus-test-ci-verifier` checks whether the change is actually covered by tests CI runs. `gitnexus-docs-dod-reviewer` turns repo guidance and linked issues into a PR-specific definition of done. `gitnexus-synthesis-critic` closes the loop, checking that the combined review is evidence-grounded and specific to GitNexus before it ships. Sources: [abhigyanpatwari/GitNexus on GitHub](https://github.com/abhigyanpatwari/GitNexus), [abhigyanpatwari/GitNexus README](https://github.com/abhigyanpatwari/GitNexus#readme) ## Common questions ### What is GitNexus? GitNexus is a Claude Code plugin that indexes a codebase into a knowledge graph of its dependencies, call chains, and execution flow, then serves that graph through its own MCP server. On top of the graph it adds 13 skills for exploring, debugging, planning, and reviewing code, plus 7 agents used in its pull request review pipeline. ### What does GitNexus's MCP server do? It is the one MCP server component in the plugin, and it answers queries against the knowledge graph once `gitnexus-cli` has built one. The repository documents it as exposing search, impact analysis, tracing, and rename operations, so an agent can query an existing index instead of rereading a repository from scratch. ### What is the difference between gitnexus-review and gitnexus-pr-swarm-review? `gitnexus-review` runs one review pass over a PR, branch, commit range, or local changes, producing a merge-risk read and a missing-test check. `gitnexus-pr-swarm-review` runs a production-readiness version of that same review through the plugin's seven agents at once, each one covering a different angle such as security, test coverage, or branch hygiene. ### What is PDG or taint analysis in GitNexus? Both are part of an optional, deeper analysis layer built on control flow and program dependence graphs. `gitnexus-taint-analysis` covers source-to-sink data flow findings, such as tracing how a value reaches an unsafe use. `gitnexus-pdg-query` queries the same graph's control and data dependence edges directly, for questions like what guards a given statement. ### How many skills and agents does the GitNexus plugin have? Flowy indexes 21 components for GitNexus: 13 skills, 7 agents, and 1 MCP server. The skills cover exploring, debugging, planning, refactoring, and reviewing code, and the 7 agents are the specialists behind its pull request review swarm. ## Related - [The listing page](https://www.flowy.sh/listings/abhigyanpatwari-gitnexus): Install command, components and repository - [Alternatives to this plugin](https://www.flowy.sh/alternatives/abhigyanpatwari-gitnexus): Peers in its category, ranked by stars - [The Claude Code plugin marketplace](https://www.flowy.sh/marketplace/plugins): How plugins install, and every plugin in the index - [superpowers for Claude Code: what it does and how to install it](https://www.flowy.sh/plugins/superpowers-flow/guide): another plugin guide - [mattpocock/skills for Claude Code: install and use](https://www.flowy.sh/plugins/matt-pocock-flow/guide): another plugin guide