GitNexus's Knowledge Graph and Review Skills for Claude Code

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 listing page linked at the top of this guide. 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.